计算机网络知识—(TCP)

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

计算机网络在IT行业的重要性

IT即互联网技术，从事的工作和网络有很大的关系，前端要负责和后台(服务器)进行交互，其必然得经过网络，所以懂点网络知识有很大的帮助。

网络模型数据处理过程

传输层协议的作用

提供了一种端到端(end to end)的连接，一般为前端和后台服务器的连接
由于网络层只管传递数据，并不关心成功与否，TCP协议在数据丢失、损坏的情况下保证数据的可靠性

传输层协议的分类

传输控制协议TCP(Transimision Control Protocal)：

可靠的、面向连接的协议
传输效率低

用户数据报协议UDP(User Datagram Protocal)：

不可靠的、无连接的服务
传输效率高

TCP

TCP的功能

为了保证TCP是可靠的、面向连接的协议，具备以下功能：

将数据进行分段打包传输，如果不将数据分段打包传输，那么会导致每次传输的数据特别大，而带宽是一定的，所以很容易造成拥塞。想象一下，一辆火车跑在公路上的感觉。
对每个数据包编号控制顺序，因为数据进行了分段打包传输，而网络中的路线不止一条，而且某些路线会有延迟的情况，没有编号，那么如何保证到达的数据是原来的模样。想象一下，将一副大拼图从一个地方，分多条路运往另外一个地方，并且没有编号。
运输中丢失、重发和丢弃处理，由于网络中的路线会有延迟，并且存在丢包现象，所以会有重发等机制来保证数据的完整性。
流量控制避免拥塞，避免发送速率过快，让接收方来不及接收，导致发生丢包。

TCP首部

源端口号和目的端口号：用来存放发送端和接收端加上IP协议首部的源端IP及终端IP，确认一个唯一的TCP连接。

32位序号：TCP用序列号对数据包进行标记，以便在到达目的地后重新重装，假设当前的序列号为 s，发送数据长度为l，则下次发送数据时的序列号为s+l。在建立连接时通常由计算机生成一个随机数作为序列号的初始值。

32位确认序号：ACK为1时有效，上次成功收到的数据字节序号+1（如接收到的为1024--2048，则返回2049），也是下一次发送端要发送数据的序列号。4位首部长度：TCP 首部的长度，单位为 4 字节。如果没有可选字段，那么这里的值就是 5。表示TCP首部的长度为 20 字节。

6个保留位：

URG => 紧急指针；
ACK => 为1表示确认序号有效；
PSH => 缓存区将满,接收方应尽快将此报文段交给应用层；
RST => 连接断了重建连接；
SYN => 同步序号为1，用来发起一个新连接；
FIN => 为1表示发端完成发送任务。

16位窗口大小：TCP流量控制，字节数，说明本地可接收数据段的数目，这个值的大小是可变的。当网络通畅时将这个窗口值变大加快传输速度，当网络不稳定时减少这个值可以保证网络数据的可靠传输。它是来在TCP传输中进行流量控制的

16位检验和：包括计算TCP首部和数据综合的二进制反码和检验和。

16位紧急指针：URG为1时有效，正向的偏移量，加上序号字段值表示最后一个字节的序号。通常在暂时中断通信时使用（比如输入 Ctrl + C）。

三次握手和四次挥手

三次握手：

第一次握手主机A通过一个标识为SYN标识位的数据段发送给主机B请求连接，通过该数据段告诉主机B希望建立连接，需要B应答，并告诉主机B传输的起始序列号
第二次握手是主机B用一个确认应答ACK和同步序列号SYNC标志位的数据段来响应主机A，一是发送ACK告诉主机A收到了数据段，二是通知主机A从哪个序列号做标记。
第三次握手是主机A确认收到了主机B的数据段并可以开始传输实际数据。

第一次握手主要是确定服务端确认客户端能够发送信号；第二次握手主要是客户端确认服务端能够接收和发送信号；第三次握手主要是服务端确认客户端能够接收信号

四次挥手：

主机A发送FIN控制位发出断开连接的请求
主机B进行响应，确认收到断开连接请求
主机B提出反方向的关闭要求
主机A确认收到的主机B的关闭连接请求

第一次挥手是服务端确认客户端需要断开连接；第二次挥手是客户端确认服务器接收断开请；第三次挥手是客户端确认服务器数据发完，断开连接；第四次挥手是服务端确认客户端断开连接，断开连接。所以如果服务端的数据全部发送完，是没有第三次挥手，直接进入第四次挥手。

TCP流量控制和TCP拥塞控制

窗口：

接收端窗口 rwnd：接收端缓冲区大小。接收端将此窗口值放在TCP报文的首部中的窗口字段，传送给发送端。
拥塞窗口 cwnd (congestion window)：发送端缓冲区大小
发送窗口swnd：发送窗口的上限值 = Min [rwnd, cwnd]，当 rwnd < cwnd 时，是接收端的接收能力限制发送窗口的最大值。当cwnd < rwnd时，则是网络的拥塞限制发送窗口的最大值

拥塞控制和流量控制的差别：

拥塞问题是一个全局性的问题,涉及到所有的主机、所有的路由器、以及与降低网络传输性能有关的所有因素。流量控制往往指的是点对点通信量的控制，是个端到端的问题。
流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。拥塞控制控制的是注入网络中的数据量。
流量窗口是接收方控制的，拥塞窗口是发送方控制的

TCP流量控制

所谓的流量控制就是接收方让发送方的发送速率不要太快，让接收方来得及接受。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。

假设主机A向主机B发送数据。双方确定的窗口值是400.再设每一个报文段为100字节长，序号的初始值为seq=1,图中的箭头上面大写ACK，表示首部中的却认为为ACK，小写ack表示确认字段的值。

下面这张接收窗口(rwnd)图和上面的数据不是对应的，但是能说明窗口大小调整的过程，可以自己将下面的图进行修改，用上面的数据分析：

刚开始的窗口值为400字节，每段报文100字节，经过发送2次请求后，此时已发送但未被确认的报文seq=201为100字节，主机B向主机A发送接收情况并调整窗口大小为300字节。
主机A向主机B发送301-500，并且重发201-300，主机B向主机A发送接收情况，并调整窗口大小为100字节
主机A向主机B发送501-600,主机B向主机A发送接收情况，并且调整窗口大小为0，让A暂停发送

假设B向A发送了rwnd=0的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段，然而这个报文段在传送中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

TCP拥塞控制

拥塞控制原理

发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就增大一些，以便把更多的分组发送出去。但是只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络的分组数。

拥塞控制设计

从控制理论的角度来看拥塞控制这个问题，可以分为开环控制和闭环控制两种方法：

开环控制就是在设计网络时事先将有关拥塞发生的所有因素考虑周到，一旦系统运行起来就不能在中途改正。
闭环控制是基于反馈环路的概念，包括如下措施：

监测网路系统以便检测拥塞在何时、何地发生
把拥塞发生的信息传送到可采取行动的地方
调整网络系统的行动以解决出现的问题。

拥塞控制方法

因特网建议标准RFC2581定义了进行拥塞控制的四种算法，即慢开始（Slow-start)、拥塞避免（Congestion Avoidance)、快重传（Fast Restrangsmit)和快回复（Fast Recovery）。我们假定：

数据是单方向传送，而另外一个方向只传送确认
接收方总是有足够大的缓存空间，因为发送窗口的大小由网络的拥塞程度来决定。

慢开始算法

最初的TCP在连接建立成功后会向网络中发送大量的数据包，这样很容易导致网络中路由器缓存空间耗尽，从而发生拥塞。因此新建立的连接不能够一开始就大量发送数据包，而只能根据网络情况逐步增加每次发送的数据量，以避免上述现象的发生。具体来说，当新建连接时，cwnd初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加至多1个MSS大小。用这样的方法来逐步增大拥塞窗口CWND。这里用报文段的个数的拥塞窗口大小举例说明慢开始算法，实时拥塞窗口大小是以字节为单位的。如下图：

拥塞避免算法

让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。

慢开始和拥塞避免轮换机制

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：

当cwnd<ssthresh时，使用慢开始算法。
当cwnd>ssthresh时，改用拥塞避免算法。
当cwnd=ssthresh时，慢开始与拥塞避免算法任意。

乘法减小和加法增大

乘法减小：是指不论在慢开始阶段还是拥塞避免阶段，只要出现超时，就把慢开始门限减半，即设置为当前的拥塞窗口的一半（于此同时，执行慢开始算法）。当网络出现频繁拥塞时，ssthresh值就下降的很快，以大大将小注入到网络中的分组数。
加法增大：是指执行拥塞避免算法后是拥塞窗口缓慢增大，以防止网络过早出现拥塞。

快重传和快恢复

一条TCP连接有时会因等待重传计时器的超时而空闲较长的时间，慢开始和拥塞避免无法很好的解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。

快重传算法并非取消了重传机制，只是在某些情况下更早的重传丢失的报文段（如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时）。快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。如下图：
快恢复算法:

当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。
考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh减半后的大小，然后执行拥塞避免算法。如图：