计算机网络（四）

一、TCP协议

传输层TCP协议

有连接：双方在发送网络数据之前必须建立连接，在进行发送。
可靠传输：保证数据是可靠并且有序的到达对端，例如发送123、456时123数据先到达，456数据后到达，但是有时可以456数据先到达传输层，但会阻塞等待先等前面的数据就是123先到达。
面向字节流：TCP发送数据的单位是以字节为单位，并且数据没有明显的边界例如：所发送的123和456就会在一起变成一个数123456。

TCP粘包问题

因为TCP协议是面向字节流的，上一次和下一次的数据没有明显的数据边界，即TCP通过recv函数接收数据的时候不会区分此条数据是第一次发送的还是第二次发送的，而是直接按规定的大小进行读取，因此有可能读取到不完整的数据或粘在一起的数据。

（例如1+1、2+2的数据不会分开而连在一起变成1+12+2的情况）

如何解决粘包？

归根结底就是一句话, 明确两个包之间的边界。

①使用定长的字节发送(不推荐)：调它的本质是设置固定的数据收发的字节大小，现实中我们发送数据有长有短，根据每条数据发送的长短给每条数据设置不同的收发长度显然不现实，所以此方法只适用于理论基础实现。
②在应用层当中，对应用程序产生的数据进行“包装”，即给应用数据头部加上描述信息，在应用数据的尾部加上分隔符。
eg：应用数据 =“aaabbbccc”   应用数据 = 应用层描述符数据的头部+“aaabbbccc”+分隔符。

UDP粘包吗？

• 对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层，就有很明确的数据边界”。
• 站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收，不会出现"半个"的情况。

二、TCP首部格式

TCP传送的数据单元称为报文段。一个TCP报文段分为TCP首部和TCP数据两部分，整个TCP报文段作为IP数据报的数据部分封装在IP数据报中，TCP报文段既可以用来运载数据，又可以用来建立连接、释放连接和应答。

其首部的前20B是固定的。TCP报文段的首部最短为20B，后面有4N字节是根据需要而增加的选项，通常长度为4B的整数倍。

细节：

TCP在在网络层ip不需要分片：

三、TCP用了哪些措施保证其可靠性?

1、序列号、确认应答、超时重传

1）TCP将每个字节的数据都进行了编号，即为序列号:TCP报文按序到达

2）确认应答(ACK)机制


3）超时重传机制

主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B。
如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发。
但是, 主机A未收到B发来的确认应答, 也可能是因为ACK丢失了。

因此主机B会收到很多重复数据， 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉。这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果。

重传的等待时间一般是2*RTT（报文段往返时间）+一个偏差值。

2、窗口机制与高速重发控制/快速重传（重复确认应答）

TCP会利用窗口控制来提高传输速度，意思是在一个窗口大小内，不用一定要等到应答才能发送下一段数据，**窗口大小就是无需等待确认而可以继续发送数据的最大值。**如果不使用窗口控制，每一个没收到确认应答的数据都要重发。

3、拥塞控制

窗口机制和拥塞控制后续单独拿出来详讲

四、连接管理机制

TCP连接都有三个阶段:连接建立、数据传送和连接释放
TCP连接的管理就是使运输连接的建立和释放都能正常进行

各状态说明

TCP三次握手

过程：客户端在发送SYN数据包后客户端的状态变为SYN_SENT，当服务端接收到客户端发送的SYN数据包后，服务端的状态变为SYN_RCVD，当客户端接收到服务端的SYN数据包和ACK数据包后，客户端的状态变为ESTABLISHED，当服务端接收到客户端发送的ACK数据包时，服务端的状态变为ESTABLISHED，此时客户端和服务端已完成三次握手，即建立了双向连接。

为什么要三次？

TCP四次挥手

补充：

数据传输完毕以后，双方都可以释放连接。在最开始的时候，客户端与服务器都是处于ESTABLISHED状态，如果客户端主动关闭，则服务端被动关闭；若服务端主动关闭，则客户端被动关闭。

为什么要四次？

五、TIME_WAIT状态

TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment
lifetime)的时间后才能回到CLOSED状态。 MSL是TCP报文的最大生存时间,
因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启,
可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的)。 同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失,
那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK)。

六、CLOSE_WAIT 状态

1）客户端进程发出连接释放报文FIN=1，并且停止发送数据。此时，客户端进入FIN-WAIT1(终止等待1）状态。这时候客户端处于一个半关闭的状态，即客户端已经没有数据需要发送了，但是服务器若要发送数据，客户端依然需要接受。
 
2）服务器收到连接释放报文后，发送确认报文ACK=1。此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。进入CLOSE_WAIT后说明服务器准备关闭连接。
 
3）客户端收到服务器的确认请求之后，此时客户端就进入了FIN-WAIT2（终止等待2）状态，等待服务器发送连接释放报文。（在这个之前还需要接受服务器发送的最后的数据）。

4）当服务器真正调用close关闭连接时, 会向客户端发送FIN=1, 此时服务器进入LAST_ACK（最后确认）状态,等待客户端的最后一次ACK回复。

5）客户端收到服务器的链接释放报文之后，必须发出确认报文ACK=1。此时，客户端就进入了TIME-WAIT（时间等待）状态，等待用户关闭套接字。注意此时TCP链接还没有释放，必须经过2*MSL（报文最大生命周期）的时间后，当客户端撤销相应的TCP后，才进入CLOSED状态。
 
6）服务器只要收到客户端发出的确认，彻底关闭连接，立即就进行CLOSED状态，于是就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。