计算机网络系列（三）传输层（中）

上回说到TCP的四次挥手，接下来继续展开说。

一 TCP的四次挥手

1.怎么挥

第一次挥手

客户端得告诉服务器它想断开连接了，它做了两件事
1）给服务器一个断开的信号，于是发送一个FIN信号；
2）客户端进入FIN_WAIT_1状态，就是准备断开状态。

第二次挥手

服务器给客户端一个收到信号的反馈，另外光给反馈还不行，假如服务器这边还在给客户端传数据呢，都传一半了，客户端突然说要断开，那剩下一半咋办？不传了？做事得有始有终，所以服务器还得抓紧时间把没传完的数据赶紧传完。所以服务器要做两件事：
1）先给客户端发送一个ACK信号，表示自己收到信号了，让客户端放心；
2）尽快把没传完的数据给传完。

第三次挥手

等把没传完的数据传完后，就可以进行第三次挥手了，这个时候服务器做两件事：
1）给客户端发送一个断开的信号，于是发送一个FIN信号；
2）服务器进入LAST_ACK状态，就是准备断开状态。

第四次挥手

客户端收到信息知道服务器已经把要发的数据都发完了，于是给服务器一个确认信息（ACK），告诉服务器它已经知道了，让服务器先断开连接,然后自己再断开连接。即做了两件事：
1）给服务器发一个确认信息，即ACK信号。
2）客户端进入TIME_WAIT状态，即等待状态，还等什么呢，如果服务器收到信息，那就回正常断开连接，这样客户端等了一会儿，知道服务器那边没事了，就也断开连接了；那如果服务器没有收到信息呢，难道服务器会傻傻等到天荒地老？不会。服务器会重复重复再重复地发送FIN片段，确认客户端收到信号没有，知道它收到客户端的信号告诉它可以断开连接了。这样客户端进入等待状态就是为了防止服务器又给它发信号，等一段时间确定服务器那边完事了，才能放心地断开连接了。

2.为啥挥四次

没有第一次挥手，服务器就不知道客户端要断开连接；
没第二次挥手，客户端就不知道服务器已经收到自己断开连接的信号；
没有第三次挥手，客户端就不知道服务器有没有把剩下的数据给传完，什么时候可以断开连接；
没有第四次挥手，客户端就不知道服务器有没有收到自己确认断开的信号，客户端也不放心直接断开连接。

二 TCP的拥塞控制

说完tcp是怎么建立连接和断开连接的，现在说说传输过程中的事情。IP包在网络中传输，经过一个个路由器最终到达服务器上，假如一个路由器上有100万个ip包，它压力山大，处理不过来，就会丢掉一些IP包。假设用UDP协议传输，那它不管传输的可靠性，丢了就丢了，偏偏TCP是个顽固的协议，它得保证传输的可靠，丢包？那我再重复发一个，直到你收到为止。这路由器本来就是因为数据包太多所以才丢掉一些的，这下又来一批，那路由器还得丢，那客户端又得重发，那还有完没完了？于是就造成了堵塞崩溃。
那怎么避免呢？在网络拥挤的时候，大家都少传点数据不就好了吗？这样给每个数据包瘦身，大家才能都通过路由器，要不瘦身，行，大家就都堵着别走了。那怎么判断网络是否拥塞呢，万一没有拥塞，我又一点一点传不是浪费时间嘛。
TCP用了四个算法进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

慢开始

客户端一下子发送大量数据字节诸如网络，容易造成网络拥塞，那一开始就小一点嘛，先试探下网络的负荷状态咋样，没问题了在慢慢增大发送窗口。
那么发送方就要有一个状态变量来确定当前发送多少报文，这个状态变量就叫拥塞窗口，如果网络不拥塞，这个状态变量就逐渐变大。
为了避免拥塞窗口太大造成网络拥塞，还得有一个状态变量来限制它，这个状态变量叫做慢开始门限。等拥塞窗口达到这个限制，就不要让它继续增大了。

拥塞避免

再慢开始中，一开始的拥塞窗口虽然很小，但如果它检查到网络负荷状态没问题，那它为了提升传输效率，每过一轮拥塞窗口会成倍地增大，而拥塞避免则是让拥塞窗口缓慢地增大，即每一轮让它加1，而不是翻倍。
那么问题就来了，啥时候让拥塞窗口成倍增大，啥时候让它缓慢地增大？
答案是，当拥塞窗口小于慢开始门限的时候，这个时候就不限制拥塞窗口，让它每轮成倍地增大；当拥塞窗口大于满开始门限的时候，这个时候就不能让它为所欲为地增大了，就让它慢慢增大。

传输过程（伪）

谈完这两种算法就可以先来看看报文的传输过程了，为什么加个（伪）呢，因为这个时候不考虑丢包的情况。
发送方最初执行慢开始，让拥塞窗口为1，只发送一个报文段，如果收到确认信号后，那就胆子大一点，只要拥塞窗口不超过慢开始门限，就让拥塞窗口每一轮成倍，反之让它慢慢增加，当没有收到确认信号，这个时候就将慢门限减半，重新执行慢开始。

快重传

以上是不考虑传输过程中丢包的情况，那丢包发生了怎么办？考虑这个情况之前，应该先考虑发送端怎么直到丢包了？
有两种情况：
1）迟迟没有收到服务器反馈的确认信息，定时器超时了。
2）收到服务器反馈三个重复的确认信息。这是什么情况呢？服务器抽了？这是因为服务器第一次收到了1，2，3三个报文，第二次收到了5，6，7三个报文，因此它认为中间有个4报文丢了，它就不会继续接受处理，而重复发回前三个报文的确认信息，因为后面收到的报文它没办法确认是对的。
那么快重传就是针对第二种情况，假设发送方一连接受到三个重复的确认信息（快速重传是选择3次ACK，两次重复的ACK不一定说明丢包了，很可能是乱序造成的！在实践中发现三次重复ACK时几乎可以肯定是丢包造成的！），那么发送方就直到有分包丢失了，这个时候就立即重传丢失的报文段，而不会等带定时器超时再重传。

快恢复

懒得继续写了，未完待续，见传输层下。

三 流量控制

四 怎样在传输层建立可靠的传输