第五章 传输层

1. 传输层概述

传输层是整个广域网体系结构模型的核心所在，负责端到端的通信，是面向网络通信的低三层和面向信息处理的高三层的中间一层。

传输层和数据链路层的作用都是建立数据传输通道，但是传输层主要体现在广域网网络应用中，可以把数据链路层当做局域网通信的数据传输通道，而传输层则是广域网中的数据传输通道。

传输层的主要作用是为它的上层提供端到端的数据传输服务。从物理的网络连接角度来讲，端到端是指网络通信的双方不是在同一条链路上，不是点对点连接的。从数据传输连接的角度来讲，端到端是指在用户看来两端的连接是直接进行的，屏蔽了核心网络结构和各个子网之间的差异。

2. 传输层服务类型

面向连接的传输服务：在提供传输服务前需要先建立专门的传输连接，而且这条连接是可管理的，在需要时或者通信结束时进行拆除。面向连接的传输服务是可靠传输服务，可提供拥塞控制和差错控制功能。

无连接的传输服务：在提供服务前不需要建立专门的传输连接，直接向目的节点发送数据，不管是否有可传输的通道，只提供不可靠的传输服务（尽力传输）。

3. 传输层端口

传输层服务访问点，用来标识应用层的进程。为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法对TCP/IP体系的应用进程进行标志，解决这个问题的方法就是在传输层使用协议端口号或端口。虽然通信的终点是应用进程，但只要把要传送的报文交到目的主机的某一个合适的目的端口，剩下的工作（即最后交付目的进程）就由TCP/UDP来完成。端口号只具有本地意义，它只是为了标志本地计算机应用层的各个进程在和传输层交互时的层间接口。

端口分类

保留端口：数值一般为0~1023。基本上都已经固定地被分配给了已知的网络协议

动态分配端口：数值为1024~49151。可以被动态地分配给任意网络服务应用程序使用，临时端口

注册端口：数值为49152~65535。固定地为某个应用服务的端口，但是它所代表的不是已经形成标准的应用层协议，二是某个软件厂商的应用程序

4. TCP与UDP的区别

TCP传输控制协议

TCP充分实现了数据传输时各种控制功能，可以进行丢包的重发控制，还可以对次序乱掉的分包进行顺序控制。TCP作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。

                                                        

UDP

UDP不提供复杂的控制机制，利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立刻按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况下，UDP也无法进行流量控制等避免网络拥塞的行为。此外，传输途中如果出现了丢包，UDP也不负责重发。甚至当出现包的到达顺序乱掉时也没有纠正的功能。

                                         

区别总结：

1. TCP面向连接；UDP面向无连接，即发送数据之前不需要建立连接
2. TCP提供可靠的服务。通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP尽最大努力交付，即不保证可靠交付
3. TCP是面向字节流的，UDP是面向报文的
4. UDP没有拥塞控制，具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。
5. 每一条TCP连接只能是点到点的；UDP支持一对一，一对多，多对一和多对多的交互通信
6. TCP对系统资源要求较多，UDP对系统资源要求较少。

         

5. 为什么UDP有时比TCP更有优势?

UDP以其简单、传输快的优势，在越来越多场景下取代了TCP,如实时游戏。

• 网速的提升给UDP的稳定性提供可靠网络保障，丢包率很低
• TCP为了实现网络通信的可靠性，使用了复杂的拥塞控制算法，建立了繁琐的握手过程，由于TCP内置在系统协议栈中，极难对其进行改进
• 采用TCP，一旦发生丢包，TCP会将后续的包缓存起来，等前面的包重传并接收到后再继续发送，延时会越来越大。而基于UDP对实时性要求较为严格的情况下，采用自定义重传机制，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成影响。

 6. 为什么TCP叫数据流模式？UDP叫数据报模式？

TCP:

所谓的“流模式”，是指TCP发送端发送几次数据和接收端接收几次数据是没有必然联系的

原因：这是因为TCP是面向连接的，一个socket中收到的数据都是由同一台主机发出，且有序地到达，所以每次读取多少数据都可以。

UDP:

所谓的“数据报模式”，是指UDP发送端调用了几次write，接收端必须用相同次数的read读完。UDP是基于报文的，在接收的时候，每次最多只能读取一个报文，报文和报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃。

原因：这是因为UDP是无连接的，只要知道接收端的IP和端口，任何主机都可以向接收端发送数据。

7. TCP和UDP分别对应的常见应用层协议

                               

TCP对应的应用层协议：

FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。

Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务，使用23端口。

SMTP：定义了简单邮件传送协议，用于发送邮件。服务器开放的是25号端口。

POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序，就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件

HTTP：从Web服务器传输超文本到本地浏览器的传送协议。

UDP对应的应用层协议：

DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。

SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。

TFTP：简单文件传输协议，该协议在端口69上使用UDP服务。

8. TCP连接

如何标识一个TCP连接：系统用一个四元组来唯一标识一个TCP连接：local ip, local port, remote ip, remote port

客户端最大TCP连接数：本地端口个数最大只有65536，端口0有特殊含义，不能使用，这样可用端口最多只有65535，所以在全部作为client端的情况下，最大TCP连接数为65535

服务器最大TCP连接数：对IPv4，不考虑ip地址分类等因素，最大TCP连接数约为232 （ip数）×216 （port数），也就是server端单机最大TCP连接数约为 。

9. TCP中两个序号和三个标记位的含义

1. seq：sequence number的缩写，表示所传数据的序号。
2. ack：acknowledgement number的缩写，表示确认号。
3. ACK：确认位，只有ACK=1的时候ack才起作用。
4. SYN：同步位，用于建立连接时同步序列。
5. FIN：终止位，用来数据传输完成后释放连接。

 10. TCP的三次握手—建立TCP连接

          

1. 第一次握手：客户端发送SYN包(seq=x)到服务器，并进入SYN-SEND状态，等待服务器确认。
2. 第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（seq=y），即SYN+ACK包，此时服务器进入SYN-RECV状态
3. 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。

三次握手详解

1. 首先，客户机与服务器的TCP进程都处于CLOSED状态，当要进行TCP连接时，客户机主动打开连接，服务器被动打开连接
2. 然后，服务器的TCP进程先创建传输控制块；此时，服务器就处于LISTEN（收听）状态。同样的，客户机也会首先创建一个传输控制块发送给服务器。这样，准备工作就做好了。
3. 现在就可以开始真正的三次握手了。首先，客户机先向服务器发送连接请求报文段，该报文段中将首部中的同步位SYN置为１（只有当SYN置为１时，才能表明客户机想要和服务器建立连接），并且随机选择一个初始序号ｘ，此时客户机进入到SYN-SENT状态。
4. 此时，服务器收到客户机的请求时，如果同意与该客户机进行连接，则需要向客户机发送确认报文。在发送报文中需要将SYN与ACK都置为１（当ACK置为1时，表明服务器同意与客户机进行连接；同时将SYN置为1，表明服务器想要和客户机建立连接），并且随机选择一个初始序号y，确认号为x+1，此时TCP服务器进程进入到SYN-RCVD阶段。
5. TCP客户端收到服务器的确认后，还要再向服务器给出确认。确认报文段中ACK置为1，确认号为ack=y+1

三次握手通俗说法

1. 客户机：服务器，我想要和你建立连接，你同意吗？
2. 服务器：客户机，我同意和你建立连接；我也想和你建立连接，你同意吗？
3. 客户机：服务器，我同意和你建立连接。

 11. 为什么会采用三次握手，若采用二次握手可以吗？

• 采用三次握手是为了防止失效的连接请求报文段突然又传送到服务器，因而产生错误。失效的连接请求报文段是指：客户端发出的连接请求没有收到服务器的确认，于是经过一段时间后，客户端又重新向服务器发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，客户端第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到服务器，服务器以为是客户端又发起的新连接，于是服务器同意连接，并向客户端发回确认，但是此时客户端根本不会理会，服务器就一直在等待客户端发送数据，导致服务器的资源浪费。
• 采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况。

 12. 如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

 13. TCP的四次挥手——断开TCP连接

                

1. 第一次挥手：客户端发送一个FIN，用来关闭客户端到服务器的数据传送，也就是客户端告诉服务器：我已经不会再给你发数据了，但是，此时客户端还可以接受数据。
2. 第二次挥手：服务器收到FIN包后，发送一个ACK给客户端，确认序号为收到序号+1。
3. 第三次挥手：服务器发送一个FIN，用来关闭服务器到客户端的数据传送，也就是告诉客户端，我的数据也发送完了，不会再给你发数据了。
4. 第四次挥手：客户端收到FIN后，发送一个ACK给服务器，确认序号为收到序号+1，至此，完成四次挥手。

 14. 为什么TIME_WAIT状态还需要等2*MSL（最大分段生存期）秒之后才能返回到CLOSED状态呢？

因为虽然双方都同意关闭连接了，而且握手的4个报文也都发送完毕，按理可以直接回到CLOSED状态，但是我们必须假想网络是不可靠的，你无法保证你最后发送的ACK报文一定会被对方收到，就是说对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

15. TCP协议如何来保证传输的可靠性

• 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据
• 对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层
• 丢弃重复数据：对于重复数据，能够丢弃重复数据
• 应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒
• 超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段
• 流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

 16. TCP粘包问题

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

为什么出现粘包现象

发送方原因：TCP默认使用Nagle算法。而Nagle算法主要做两件事：1）只有上一个分组得到确认，才会发送下一个分组；2）收集多个小分组，在一个确认到来时一起发送。所以，正是Nagle算法造成了发送方有可能造成粘包现象。

接收方原因：TCP接收到分组时，并不会立刻送至应用层处理，或者说，应用层并不一定会立即处理；实际上，TCP将收到的分组保存至接收缓存里，然后应用程序主动从缓存里读收到的分组。这样一来，如果TCP接收分组的速度大于应用程序读分组的速度，多个包就会被存至缓存，应用程序读时，就会读到多个首尾相接粘到一起的包。

什么时候需要处理粘包现象

如果发送方发送的多个分组本来就是同一个数据的不同部分，比如一个很大的文件被分成多个分组发送，这时，当然不需要处理粘包的现象。但如果多个分组本毫不相干，甚至是并列的关系，我们就一定要处理粘包问题了。

如何处理粘包现象

发送方：对于发送方造成的粘包现象，我们可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭Nagle算法。

接收方：遗憾的是TCP并没有处理接收方粘包现象的机制，我们只能在应用层进行处理。

应用层处理：应用层的处理简单易行，并且不仅可以解决接收方造成的粘包问题，还能解决发送方造成的粘包问题。解决方法就是循环处理：应用程序在处理从缓存读来的分组时，读完一条数据时，就应该循环读下一条数据，直到所有的数据都被处理

17. TCP拥塞控制

发生拥塞控制的原因：资源的需求>可用资源

作用：拥塞控制就是为了防止过多的数据注入到网络中，这样可以使网络中的路由器或者链路不至于过载

拥塞控制和流量控制的区别:

拥塞控制是一个全局的过程，涉及到所有的主机、路由器、以及降低网络相关的所有因素。流量控制往往指点对点通信量的控制，是端对端的问题。

拥塞控制的几个指导原则:

1. 一个丢失的报文段意味着拥塞，因此当报文段丢失时应该降低TCP发送方的速率
2. 当一个确认的报文段到达时，表示当前网络是顺畅的，即可以提升发送方的速率
3. ACK和丢包事件充当了隐式的信号，指导着拥塞控制

拥塞控制的方法：

1. 慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小
2. 拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
3. 快重传：快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
4. 快恢复：当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半，但是接下去并不执行慢开始算法。因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

• 点赞
• 收藏
• 分享
• 文章举报

冰菓~ 发布了10 篇原创文章 · 获赞 4 · 访问量 434 私信 关注