随意谈谈tcp

Posted 2021-12-15 bewolf

tcp作为四层中可靠到传输协议，为上层协议提供了字节流的可靠到传输，之所以能做到可靠主要因为以下几点：

1、流与分段：流即字节流，计算机处理程序时一般以字节为单位，如果上层协议接收到到是字节流并且跟发送时候字节流顺序相同那么会非常舒服。但大量的字节流都塞到一个报文中传输会有些问题，网络设备都有自己到最大传输单元，如果报文超过传输单元会被丢弃，所以tcp会将要传输到字节流进行分段传输。

2、应答：每一段都会有一个序号，接收端会将接收到到报文按照序号进行序号加1（可以理解成下一个期望接收的序号）的应答。

3、滑动窗口和流量控制：IP层的报文传输是不保序的，这就导致一个后面tcp的分段可能先到，比如发送端发送 1 2 3 4 5 个分段报文，接收端可能收到的顺序是1 2 5 4 3，这样为了在接收端保序，一个很容易的方法就是按照顺序接收，没按照顺序到来的报文直接丢掉，依靠重传机制，比如上述例子中，接收到收到1 2报文之后，接收到了5，发现没按照顺序，则直接丢掉，然后接收到4也丢掉，然后接收到3，等4到重传接收，然后等5，这样可以达到保序到要求，但是大量到丢报文，重传会导致效率较低。另一个极端到想法就是把不按照顺序来到报文缓存到本地，直到所有到报文都接收到再送给上层协议，但这样做也有一个问题，就是不知道设备上会有多少没按照顺序但报文，这样都缓存在本地的话，根本不知道会用多少内存。所以就有了个折中的办法---滑动窗口，滑动窗口可以理解缓存。超出缓存的才丢掉，缓存内的就放着等收齐了上报。

    实际上发送方和接收方都有滑窗，发送方的滑窗可以理解为对发送报文速度的限制，如果只在接收方缓存，而发送方不受限制，将会导致大量报文在缓存外，造成资源浪费。

发送方滑窗：

 offered window为整个滑窗的大小，可以分为下面两个部分发送但未接收到应答部分和可用于发送到部分。

接收方滑窗：

 

接收方的滑窗相对于发送方的滑窗多了一个"Received; ACKed; Not Sent to Proc"的部分，接收方接收到的文本流必须等待进程来读取。如果进程正忙于做别的事情，那么这些文本流即使已经正确接收，还是需要暂时占用接收缓存。另外就是已经接收但未来得及应答但部分和未使用的部分。

现在还有一个问题，发送方的滑动窗口应该设置多大？这个其实是在报文交互过程中由接收方通知的，接收方根据自己接收能力，通知发送方自己期望的窗口大小。这样通过调整窗口的大小也自然的起到了流量控制的目的。

4、丢包重传：每一个分段在接收到收到之后都会进行确认。发送端发送报文之后会启动定时器，如果定时器超时还没收到这段的回复，则认为是丢包，那么会重传。

5、拥塞控制：本质上就是限制自己的行为，发现网络拥堵的时候减少自己发送报文的速度，发现网络不拥堵则多发报文。发送方有自己的拥塞窗口，会根据用塞算法调整这个窗口。