有关TCP协议的思考 （可靠传输 流量控制 拥塞控制）

之前写过一篇有关网络层的ip协议设计相关的想法，关于tcp我同样来一篇。其实了解TCP协议就必须要了解其首部的每个字节的意义。TCP是可靠传输，传输数据之前必须建立连接 最后也要释放连接。所以要我们自己设计，应该有哪些字段呢？首先应该是目的端口号、源端口号 用于进程到进程的通信。其次序号和确认号 即对每个字节编号，不管是停止等待ARQ还是连续ARQ都是需要知道哪个字节的数据是否收到，那么就需要编号。确认号是告诉对方下一次该从哪个编号的字节开始发送数据。然后 是ACK FIN SYN 等标志位 用于连接相关。还有就是首部长度 即数据偏移 和校验和。最后是窗口 用于告诉对方我这边还能接受多大的数据，用于拥塞控制。对于TCP MSS 默认为536 （+ 20 = 556 ），对于为什么设置MSS 即最大TCP报文长度，我们知道报文起码不能太小，如果太小的话，导致头部占比过大，如果过大的话，网络层还得分片，之后在接收方把分片在组装起来。增大开销。

tcp超时重传是可靠传输的关键，概念是非常简单的，那么超时重传的时间如何选择呢？
答：我们知道如果重传时间过小 会造成不必要的重传，如果超时重传时间过大，则会使得网络空闲时间变大，降低效率。如何设置？TCP采用的是一种自适应算法:新的RTTs = (1 - a) * 旧的RTTs + a新的RTT样本。显然超时重传时间应该大于RTTs。所以RTO= RTTs+4 RTTd(其中RTTd 代表平均RTT偏差 计算方法 为RTTd = (1 -b) * 旧的RTTd + b*(RTTs - 新测的RTT 绝对值))

有一个问题就是假设某个编号数据的定时器到时了，需要重新传送，但是之前的并不是接收方未收到而是确认报文在网络中滞留较长时间，但是发送发收到此确认报文后不知道是对哪一次的确认。从而会导致RTO偏大或者偏小。解决办法是：当报文重传时候就不要再计算RTTs 和RTTd了，只适当的增大一些RTO。

TCP的流量控制如何实现？
我们之前在说tcp字段的时候，有个窗口字段，该字段就是告诉对方我现在接收缓冲区接收这么大小的数据合适，你也不要大于这个数。所以利用该字段可以在接收方控制发送方的发送速率，从而进行了流量控制。
补充说明:流量控制利用超时重和确认机制，在发送方发送过快的情况下接受方无法及时处理收到的分组，那么就会造成分组的丢失。可以利用TCP数据包中的window size字段告诉发送方我的接受窗口就这么大，不要发送太快。这样就达到了目的。是可靠性的一种体现。

为什么会有网络拥塞？TCP是怎么进行网络拥塞控制的？
我们知道数据传输需要 一定的链路带宽、处理结点的缓存 以及处理器等等，当流量过大，要求的资源无法得到满足时，就会发生网络拥塞。比如路由器缓冲区溢出了无法接受转发更多的分组，那么只能丢弃这些溢出的分组，从而发送方超时重传，但是若该节点的处理速度得不到提高说不定会使得整个网络的情况恶化。我们一定要明白网络拥塞是一个全局性问题，包含网络中的所有的链路所有的主机、路由器等，它与流量控制不同的是流量控制注重的端到端的问题，控制发送方发送数据不要太快导致接收方不能有效的接收所有数据。
首先是"慢开始"算法:即将拥塞窗口设置为1个MSS,之后没收到一个报文段的确认就增加一个MSS。这样慢开始其实是类似于指数式增长的。当增长的某个限度时，需要进行"拥塞控制算法"即进行线性增长，线性增长的时候发生拥塞的时候，则将限定值调整为发生拥塞的窗口到的一半。
有个问题是可能发生假性拥塞，即个别报文在网络中会发生丢失，但是并不是网络发生了拥塞，避免这种情况的方法就是对于未按顺序收到的报文 连发3个ack提示发送方立即重发，发送方收到3ACK后就明白不是网络拥塞，将限定值定为现在窗口的一半，同时将拥塞窗口定为一样的值，开始拥塞避免算法-线性增长

TCP 作为传输层协议一般不会在网络层发生分片，原因是什么？
TCP 中有MSS(MAx segment size)来定义此次连接后双方传输的最大TCP 段大小，之后不能超过这个值，一般将MTU 作为参考值，即数据链路层的数据字段最大1500，而ip头最小20 tcp头20 所以MSS一般定位1460字节。这样的片段在网络层自然不会分片。