计算机网络-传输层

一 OSI和DoD模型

 

 传输层最大数据包是65535字节，而网络层数据最大只有1480字节。所以需要分段，但是只要分段，就有可能丢包，因为网络层不负责可靠传输。

一、运输层

1.1运输层的作用 ：

　　网络层为主机之间提供逻辑通信，而传输层为应用进程之间提供端到端的逻辑通信。

　　

 

1.2 传输层的两个主要协议

　　（1）用户数据报协议（UDP）

　　 （2）传输控制协议（TCP）

　　UDP在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP报文后，不需要给出任何确认（即不提供可靠交付）。

　　TCP则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务。由于TCP要提供可靠地、面向连接的运输服务，因此不可避免的增加了许多开销。

　

 

二、用户数据报协议UDP

1.UDP主要特点

　　（1）UDP是无连接的，即发送数据之前不需要建立连接。

　　（2）UDP使用尽最大努力交付，即不保证可靠交付。

　　（3）UDP是面向报文的。UDP对应用层交下来的报文，既不合并也不拆分，而是保留这些报文的边界，这就是说，应用层交给UDP多长的报文，UDP就照样发布，即一次发送一个报文。

　　（4）UDP没有拥塞控制。因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用很重要。

　　（5）UDP支持一对一、一对多、多对一和多对多的交互通信。

　　（6）UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。

三、传输控制协议TCP　

1.TCP的主要特点

　　（1）TCP是面向连接的运输层协议；

　　（2）每一条TCP连接只能有两个端点，每一条TCP连接只能是点到点的（一对一）；

　　（3）TCP提供可靠交付的服务；

　　（4）TCP提供全双工通信；

　　（5）面向字节流；“面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义；

2.TCP可靠传输的实现

　　问：TCP如何保证可靠性？

https://www.jianshu.com/p/42dbcd39c3e7

1. 超时重传
2. 连接管理机制
3. 流量控制
4. 拥塞控制
5. 确认应答ack与序列号seq
6. 校验和

　　2.1 滑动窗口机制　　

 

　　对于发送端来说，即将要发送的数据包排成一个队列，对于发送者来说，数据包总共分成四类。分别是在窗口前的，已经发送给接收方，并且收到了接收方的答复，我们称之为已发送。在窗口中的，有两种状态，一个是已经发送给接收方，但是接收方还没确认送达，我们称之为已发送未确认，另外一个是可以发送了，但是还没有发送，我们称之为允许发送未发送。最后的是在窗口外面的，我们称之为不可发送，除非窗口滑到此处，否则不会进行发送。就这样，一旦前面的数据已经得到服务端确认了，这个窗口就会慢慢地往后滑，后面新的数据包就由不可发送待发送变成了可发送状态了。

　　注意上图中接收端，B只能对按序收到的数据中的最高序号给出确认，因此B发送的确认报文段中的确认号仍然是31 (即期望收到的序号)，而不能是32或33。

　　2.2滑动窗口机制的作用：

　　　　有了滑动窗口，通信双方就不用发送一个报文后，收到此报文的确认后再发送下一个报文，而是可以连续发送多个报文，只要别超过窗口大小限制；还有就是：TCP开销比udp大，一旦网络拥塞或报文丢失又会造成报文重发，而这些重发又加重了拥塞，所以TCP里要严格控制发送速率防止网络拥塞，滑动窗口根据接收方的Win大小很好的限制了发送方的发送速率。

总结就是：（1）滑动窗口允许发送方连续发送多个报文（2）根据对方接收窗口大小限制发送方的发送速率，防止拥塞

3.TCP的拥塞控制

　　3.1定义：

　　　　所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

　　3.2TCP的拥塞控制方法

　　　　问：简述TCP拥塞控制：

　　只要网络中没有出现拥塞，拥塞窗口的值就可以再增大一些，以便把更多的数据包发送出去，但只要网络出现拥塞，拥塞窗口的值就应该减小一些，以减少注入到网络中的数据包数。

• 慢启动阶段思路是不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小，在没有出现丢包时每收到一个 ACK 就将拥塞窗口大小加一（单位是 MSS，最大单个报文段长度），每轮次发送窗口增加一倍，呈指数增长，若出现丢包，则将拥塞窗口减半，进入拥塞避免阶段；
• 当窗口达到慢启动阈值或出现丢包时，进入拥塞避免阶段，窗口每轮次加一，呈线性增长；当收到对一个报文的三个重复的 ACK 时，认为这个报文的下一个报文丢失了，进入快重传阶段，要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方，可提高网络吞吐量约20%）而不要等到自己发送数据时捎带确认；
• 快重传完成后进入快恢复阶段，将慢启动阈值修改为当前拥塞窗口值的一半，同时拥塞窗口值等于慢启动阈值，然后进入拥塞避免阶段，重复上述过程。

　　　　（1）慢开始 （2）拥塞避免 （3）快重传 （4）快恢复

 　　（1）慢开始

　　慢开始算法的思路是这样的:当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络，那么就有可能引起网络发生拥塞。经验证明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。（每经过一个传输轮次，拥塞窗口cwnd就加倍）

　　  （2）拥塞避免　

　　拥塞避免算法的思路是让拥塞窗口cwnd 缓慢地增大，即每经过一一个往返时间RTT就把发送方的拥塞窗口cwnd加1”，而不是像慢开始阶段那样加倍增长。因此在拥塞避免阶段就有“加法增大”AI (Additive Increase)的特点。这表明在拥塞避免阶段，拥塞窗口cwnd按.线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
　　  （3）快重传

　　有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口cwnd又设置为1,因而降低了传输效率。.采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序.的报文段也要立即发出对已收到的报文段的重复确认。如图5-26所示，接收方收到了M1和M2后都分别及时发出了确认。现假定接收方没有收到M3但却收到了M4。 本来接收方可以什么都不做。但按照快重传算法，接收方必须立即发送对M2的重复确认，以便让发送方及早知道接收方没有收到报文段Ms。发送方接着发送M5和M6。接收方收到后也仍要再次分别发出对M2的重复确认。这样，发送方共收到了接收方的4个对M2的确认，其中后3个都是重复确认。快重传算法规定，发送方只要- -连收到3个重复确认，就知道接收方确实没有收到报文段M3，因而应当立即进行重传(即“快重传”)，这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。使用快重传可以使整个网络的吞吐量提高约20%。


　　　（4）快恢复　　

　　因此，在图5-25中的点❹，发送方知道现在只是丢失了个别的报文段。于是不启动慢开始，而是执行快恢复算法。这时，发送方调整门限值ssthresh= cwnd/ 2= 8，同时设置拥塞窗口cwnd = ssthresh=8 ( 见图5-25中的点❺)，并开始执行拥塞避免算法。

3.3 拥塞窗口与滑动窗口的区别

两者都是在调整主机发送数据包的速率。不同之处是：

滑动窗口是解决Flow Control的问题，就是如果接收端和发送端对数据包的处理速度不同，如何让双方达成一致。

而拥塞窗口是解决多主机之间共享网络时出现的拥塞问题的一个修正。客观来说网络信道带宽不可能允许所有主机同时全速通信，所以如果全部主机都全速发送数据包，导致网络流量超过可用带宽，那么由于TCP的设计数据包会大量丢失，于是由于重传机制的触发会进一步加剧拥塞，潜在的导致网络不可用。

4.TCP的运输连接管理

4.1 三次握手

 

TCP报文中比较重要的字段：

（1）序号（sequence number）：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

（2）确认号（acknowledgement number）：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=Seq+1。

（3）标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：

URG：紧急指针（urgent pointer）有效。

ACK：确认序号有效。

PSH：接收方应该尽快将这个报文交给应用层。

RST：重置连接。

SYN：发起一个新连接。

FIN：释放一个连接。

 

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

进行三次握手：

第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号seq =x。此时客户端处于 SYN_SEND(同步已发送) 状态。

第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号seq = y。同时会把客户端的 x + 1 作为确认号ack 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD （同步收到）的状态。

第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 y + 1 作为确认号ack的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 标志位ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

问 ： 为什么三次握手而不是两次？

　　主要是防止已失效的连接请求报文段突然又传送到了B.

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

4.2 四次挥手

　　建立一个连接需要三次握手，而终止一个连接要经过四次挥手。这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

　　TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，客户端或服务器均可主动发起挥手动作。

刚开始双方都处于 ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

 

第一次挥手：客户端发送一个 FIN （连接释放）报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态（终止等待1状态）。

第二次挥手：服务端收到 FIN 之后，会发送确认报文，且把客户端的序列号值 +1 作为确认报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态（关闭等待状态）。

第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态（最后确认状态）。

第四次挥手：客户端收到 FIN 之后，一样发送一个 确认报文作为应答，且把服务端的序列号值 +1 作为自己确认报文的序列号值，此时客户端处于 TIME_WAIT 状态（时间等待状态）。需要过一阵子以确保服务端收到自己的确认报文之后才会进入 CLOSED 状态，服务端收到确认报文之后，就处于关闭连接了，处于 CLOSED 状态。

问：为什么需要四次挥手？

　　因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

问：为什么A在Time-Wait状态必须等待2MSL时间？

1MSL:报文最大生存时间,他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃

第一，为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常的步骤进入CLOSED状态。
第二，A在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。

 

https://zhuanlan.zhihu.com/p/86426969