计算机通信协议中的TCP为什么叫通信协议，什么是TCP协议？

计算机通信协议的tcp称为传输控制协议，它是互联网数据传输的“快递员”，负责把数据可靠地送到对端。TCP位于TCP/IP协议栈的传输层，与IP协议配合，一个负责“找路”，一个负责“保证送达”，今天这篇文章，我们就从TCP的定位、工作机制、对比差异到实际应用，把这位“快递员”掰开揉碎讲清楚。

tcp协议在哪个层，它和ip协议是怎么分工的

很多刚入门的朋友会混淆TCP和IP,其实它们各司其职，TCP/IP协议族是一个分层模型，从上到下依次是应用层、传输层、网络层、网络接口层。TCP属于传输层，IP属于网络层。

打个比方,IP协议就像快递公司的分拣中心，它只管把包裹（数据包）按照地址送到正确的城市，至于包裹在途中有没有破损、有没有丢失，IP不管，而TCP就是那个随车押运的质检员，它负责在发出端和接收端之间建立一条“虚拟通道”，把数据编上序号，接收方收到后要回执确认，没收到就重发。

行业共识认为,TCP/IP这一组合之所以能统治互联网数十年，正是因为“开放寻址”和“可靠传输”这两件事被解耦了，IP负责尽力而为地转发，TCP负责在不可靠的网络上“硬生生”造出一个可靠连接。

计算机通信协议的tcp称为传输控制协议，它的“三次握手”到底在做什么

TCP被称为“面向连接”的协议，这个连接不是物理上拉一根线，而是通过一系列控制报文在两端“约定”出一个状态，最常见的建立连接过程就是三次握手。

• 第一次握手：客户端发送一个SYN报文（同步序列编号），告诉服务器“我要建立连接，我的初始序号是X”。
• 第二次握手：服务器收到后，回复SYN+ACK报文，意思是“你的SYN我收到了，我这边也准备好了，我的初始序号是Y”。
• 第三次握手：客户端再发送一个ACK报文，意思是“我也收到你的SYN了，连接正式建立”。

为什么必须是三次,而不是两次？这里面最关键的点在于防止历史重复连接初始化，如果只握手两次，客户端一个迟到的SYN报文可能让服务器误以为是一个新连接，从而白白分配资源，三次握手让客户端有机会告诉服务器“我这个SYN已经过期了，你别当真”。

业内专家指出,三次握手的设计在保证效率的同时，避免了至少一半的异常资源占用问题，实际抓包时，你会看到TCP三次握手的抓包标志位依次是

SYN → SYN, ACK → ACK，三个报文缺一不可。

三次握手的“半连接队列”和“全连接队列”

在Linux服务器上,TCP建连过程还有两个重要的队列，这也是面试和故障排查的高频考点。

• 半连接队列：存放已经收到SYN但还没完成三次握手的连接（SYN_RECV状态）。
• 全连接队列：存放已完成三次握手、等待应用层accept()取走的连接（ESTABLISHED状态）。

当服务器负载过高时,通常表现为全连接队列被占满，新连接无法建立，排查时可以用 ss -lnt 命令查看 Send-Q 和 Recv-Q 这两个值是否溢出。Recv-Q 长期等于 Send-Q，说明应用层处理不过来，这时候优化业务逻辑比调内核参数更管用。

tcp协议和udp协议的区别，实际场景下怎么选择

既然TCP这么可靠,为什么还有UDP（用户数据报协议）的存在？因为可靠性是有代价的。TCP的可靠建立在确认、重传、排序、拥塞控制这些机制上，代价是速度和额外的带宽开销。

为了让你直观理解,我用一个表格对比两者的核心差异：

在实际选型中,tcp协议和udp协议的区别直接决定了业务的体验，比如你下载一个文件，丢一个包这文件就坏了，必须用TCP，但如果你在看视频直播，偶尔丢几帧画面其实感知不强，用UDP反而能降低延迟，避免因为TCP重传导致画面卡顿。

具体场景建议如下：

• 需要100%完整数据的场景（网页HTTP、文件FTP、邮件SMTP），选TCP。
• 实时性要求极高、能容忍少量丢失的场景（RTP音视频、游戏同步、QUIC协议的底层），选UDP。
• 如果拿不准,默认选TCP，因为绝大多数应用层协议（HTTP、HTTPS、SSH）都跑在TCP之上。

tcp的可靠传输是如何做到的，滑动窗口和拥塞控制浅析

TCP的“可靠”不是靠运气，而是靠一套组合拳，除了前面说的序号和确认号，还有两个核心机制：滑动窗口和拥塞控制。

滑动窗口：传输效率的“油门”

如果没有窗口机制,TCP得发一个包等一个确认，这叫做“停等协议”，效率极低，滑动窗口允许发送方一次性发送多个数据包，然后等待累计确认，窗口越大，网络吞吐量越高。

但窗口不能无限大,它受两个因素限制：

• 接收方的接收能力（接收窗口，rwnd）。
• 网络本身的承载能力（拥塞窗口，cwnd）。

实际发送窗口取这两个值中的较小者,如果你用TCP传大文件时速度上不去，可以用 iperf 工具测试，并尝试调整socket缓冲区大小（/proc/sys/net/ipv4/tcp_rmem 和 tcp_wmem）来观察吞吐变化。

拥塞控制：避免“网络堵车”

当网络出现拥堵时,如果发送方还拼命发数据，只会加剧拥堵，TCP的拥塞控制核心算法是慢启动、拥塞避免、快重传、快恢复。

• 慢启动：连接建立初期，cwnd从1开始，每收到一个确认就翻倍，指数增长。
• 拥塞避免：当cwnd达到阈值（ssthresh），改为线性增长，每次RTT加1。
• 快重传：收到3个重复ACK，立即重传丢失报文，不等超时。
• 快恢复：把ssthresh降为当前cwnd的一半，然后进入拥塞避免阶段。

在Linux上,你可以通过 ss -ti 查看当前TCP连接的拥塞控制算法和cwnd值，现代内核默认使用 cubic 算法，而Google推出的BBR算法在长肥网络上有更好的表现，不少云厂商已经默认启用。

实际排查TCP问题常用的几个命令和操作路径

空谈理论没有用,运维开发中遇到TCP问题，这些命令是你的“显微镜”和“手术刀”。

查看建立的连接状态

netstat -ant | grep ESTABLISHED ss -s # 汇总统计

如果看到大量 TIME_WAIT 状态的连接，说明主动关闭连接的一方在频繁处理短连接，这个状态会持续2MSL（最长报文段寿命的2倍），通常为60秒，过多的话可以开启 tcp_tw_reuse 来复用。

抓包分析三次握手

tcpdump -i eth0 host 192.168.1.10 and port 80 -w tcp.pcap

抓完包后用Wireshark打开,在过滤栏输入 tcp.flags.syn==1 就能过滤出所有握手报文，如果只看到SYN发出而没有SYN+ACK回应，多半是被防火墙拦了或者服务器端口没监听。

查看重传率

netstat -s | grep -i retrans

如果重传率很高,说明网络丢包严重，这时候用 mtr 命令可以逐跳检测哪个节点丢包最厉害。

关于tcp传输控制协议的常见问题解答

TCP连接为什么不是“两次握手”或者“四次握手”？

两次握手的缺陷是无法防止“已失效的连接请求报文段”突然又传到服务端，导致服务端白白建立连接、分配资源，四次握手则没有必要，因为客户端确认服务端的SYN可以和客户端的ACK合并成一个报文，三次握手已经是最小且安全的通信次数。

TCP协议在哪个层，它直接暴露给应用层使用吗？

TCP位于传输层,应用层的进程通过Socket编程接口来使用TCP，开发者不需要直接操作TCP报文，而是调用 socket()、bind()、listen()、connect() 这些系统函数，内核会完成TCP报文段的封装、序号分配、重传等细节，例如用Python写一个简单的TCP服务端，只需三行核心代码就能监听端口接收数据。

TCP和HTTP有什么关系，为什么说HTTP跑在TCP上？

HTTP是应用层协议,它规定了请求和响应的格式（比如GET、POST方法，状态码等），但HTTP本身不负责数据传输，当你在浏览器输入网址时，浏览器会先通过TCP与服务器建立连接，然后把HTTP报文作为数据载荷交给TCP发送，正是因为TCP的可靠传输，HTTP才能假定“发出的请求一定被服务器收到，收到的响应一定完整”，所以如果你经常遇到“连接被重置”的错误，本质上就是TCP层传来的异常信号。