客户端向服务端发送SYN，申请建立客户端到服务端的连接
服务端返回ACK（第一次SYN的应答）和SYN，申请建立服务端到客户端的连接
客户端收到数据，状态置为ESTABLISHED，表示客户端到服务端连接建立完成，并且发送ACK（第二次SYN的应答），服务端收到数据，状态置为ESTABLISHED，表示服务端到客户端的连接建立完成

三次握手主要是为了检查当前网络的情况是否满足可靠运输的基本条件，同时也是在检测双方发送和接收数据的能力是否正常

四次挥手

【计算机网络】TCP协议详解「终于解决」

说明：关闭的时候服务端申请关闭或者客户端申请关闭都可以

客户端发送FIN到服务端，申请关闭客户端到服务端的连接
服务端收到FIN状态置为CLOSE_WAIT，并返回ACK应答（这个动作是系统实现TCP协议栈默认执行的，不需要程序来调用代码）
服务端发送FIN到客户端，申请关闭服务端到客户端的连接（程序手动调用socket.close发送）
客户端收到FIN返回ACK应答，并进入TIME_WAIT时间等待状态，客户端等待一段时间后，状态置为CLOSED，服务端收到应答后，状态置为CLOSED

思考：

为什么服务端不将ACK和FIN合并一起发送，形成三次挥手呢？

答：主要是ACK和FIN的发送时机不同，ACK是操作系统内核响应的（立即执行），而此时服务端还可能在继续发送数据，待处理完数据后由程序调用close方法后才发送FIN

为什么客户端要等待一段时间状态才置为CLOSED，而不之间将状态置为CLOSED？

答：如果客户端给服务端的ACK丢包后，服务端得重新给和客户端发送FIN，此时客户端得给服务端应答，所以此时状态不能置为CLOSED，得等待一段时间（2MSL，MSL为网络上任意两点传输的最大时间）确保服务端收到客户端的应答

2.1.4 流量控制

接收端主机处理数据的速度有限，如果发送端发送数据太快，导致接收端缓冲区被填满，这时，发送端继续发送数据的话就会造成丢包，继而引起丢包重传等一些列连锁反应，因此TCP协议根据接收端接收数据的能力，来决定发送端发送数据的速度，这个机制就叫作流量控制

接收端将自己剩余缓冲区大小存入TCP头部中的“16位窗口大小”字段，通过ACK通知发送端
窗口大小越大，说明网络吞吐量越高
发送端根据接收到这个窗口的大小，控制自己的发送速度
如果接收缓冲区满了，就会将窗口设置为0，这时，发送端不在发送数据，而是定期的发送一个窗口探测报文（只是为了知道窗口的大小），让接收端将窗口大小告诉发送端

2.1.5 拥塞控制

刚开始发送数据时，由于中间结点的网络情况不清楚，如果贸然发送大量数据，就会造成大量丢包，所以TCP协议引入慢启动的方式，先发少量数据探探路，再决定按照多大速度发送数据

此处引入拥塞窗口，刚开始时，拥塞窗口设置为1，每收到一个ACK时，拥塞窗口加1，每次发送数据的时候，拥塞窗口和流量窗口的较小的值作为实际发送的窗口，即滑动窗口的大小

注意：上述增长方式是指数级别的，指数式增长可以快速接近丢包的极限

拥塞窗口变化的方式

为了不增长那么快，引入一个慢启动的阈值，当拥塞窗口的大小超过了这个阈值，不在按照指数方式增长，而是按照线性方式增长，如下图所示：

【计算机网络】TCP协议详解「终于解决」

开始时，慢启动的阈值为窗口的最大值，线性增长到一定程度时会发生丢包
网络拥塞时，拥塞窗口置1，慢启动阈值变为拥塞窗口/2，重新开始增长

2.2 效率机制

2.2.1 滑动窗口

前面的确认应答机制指出，对每一个发送的数据都对应有一个ACK确认应答，这样采取一发一收的方式有一个很大的缺点就是效率太差，为了提高效率采用滑动窗口，即一次性发送多个数据

【计算机网络】TCP协议详解「终于解决」

窗口大小：指无需等待而可以继续发送数据的最大值，上图的窗口大小为4000个字节（四个段）
具体如何设置窗口大小：min(流量窗口的大小，拥塞窗口的大小)
窗口如何滑动：接收到的ACK下一个是n，滑动到n-1的位置

操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答，只有应答过的数据才能从缓冲区中删掉

如果出现了丢包，如何确保可靠传输？

情况一：数据已经收到，返回的ACK应答丢包

【计算机网络】TCP协议详解「终于解决」

这种情况下，部分ACK丢了不要紧，因为可以通过后续的ACK进行确认

情况二：发送数据的时候就已经丢包

【计算机网络】TCP协议详解「终于解决」

说明：

当1001~2000这段报文丢失后，发送端一直会收到1001这样的ACK
如果发送端主机连续三次收到相同的ACK如1001应答，那发送端主机就会重新发送1001~2000数据
此时，接收端收到1001~2000数据后，再次返回的ACK应答就是7001了，因为2001~7000数据都已经接收到了，被放到接收端操作系统内核的接收缓冲区了

这种机制，即时不超时也会发生重传，称作“高速重发控制”也叫“快重传机制”

2.2.2 延迟应答

如果接收端主机接收到数据时，立刻返回ACK应答，这时候返回的流量窗口就比较小，但是流量窗口越大，网络吞吐量越大，传输效率就越高，所以等待一部分时间，待接收端处理完一部分数据，就可以将流量窗口设置为大一点的值，这样网咯吞吐量大，效率高

延迟是为了高吞吐量，但是也不能无限延迟

数量限制，每隔n个包就应答一次
时间限制，超过最大延迟时间，就应答一次

具体的数量和时间，不同操作系统有差异，一般n取2，超时时间取200ms

2.2.3 捎带应答

服务端接收到客户端的消息后，因为延迟应答机制，导致ACK不一定立即返回，可能ACK返回的时机和应用代码中返回响应的时机重合了，此时九江

3. 粘包问题

TCP是面向字节流的，可以多次的接收和发送，对于应用层来说，一连串的字节数据，不知道从哪到哪算一个完整的应用层数据包，对应发送多少次算一个应用层完整格式的数据，和接收多少次算一个应用层完整格式的数据就不知道了

如何解决粘包问题？明确包的边界

对于定长的包，每次都按照固定大小读取即可
对于变长的包，可以在包与包之间明确分隔符（应用协议，程序员自己定，只要保证分隔符和正文不起冲突即可）

4. TCP的异常情况

进程终止：进程终止会释放文件描述符，仍然可以发送FIN，和正常关闭没有什么区别
机器重启：和进程终止的情况相同
机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了就会进行reset，即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在，如果对方不在，也会把连接释放
另外，应用层的某些协议，也有一些这样的检测机制，例如HTTP长连接中，也会定期检测对方的状态，例如QQ，在QQ断线之后，也会定期尝试重新连接

5. TCP协议特点总结

有连接：通过三次握手建立连接后才可接发数据，TCP协议是全双工的，即每端既可以发也可以收
可靠传输：网络数据传输是一跳一跳的，经过路途中的设备可能发生数据丢失，可靠传输是可能发生数据丢失但有机制保证对方能接收到
面向字节流：可以多次的收发数据（连接没有关闭时，可以多次的接收和发送数据）
有接收缓冲区和发送缓冲区：发送数据时，是先写到发送缓冲区，再刷新缓冲区（flush）
大小不受限制：多次的收发数据，每次的数据可以很大

6. 基于TCP的应用层协议

HTTP
HTTPS
SSH
Telnet
FTP
SMTP

也包括自己写TCP程序时自定义的应用层协议

免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://yundeesoft.com/24969.html

【计算机网络】TCP协议详解「终于解决」

1. TCP协议头部格式

2. TCP协议原理

2.1 可靠传输机制

2.1.1 确认应答机制

2.1.2 超时重传机制

2.1.3 连接管理机制（三次握手，四次挥手）

2.1.4 流量控制

2.1.5 拥塞控制

2.2 效率机制

2.2.1 滑动窗口

2.2.2 延迟应答

2.2.3 捎带应答

3. 粘包问题

4. TCP的异常情况

5. TCP协议特点总结

6. 基于TCP的应用层协议

相关推荐

发表回复