TCP/IP_TCP与UDP

电玩女神 2022-05-21 11:29 259阅读 0赞

## TCP/IP\_TCP与UDP ##

TCP/IP中两个具有代表性的传输层协议，他们分别是TCP和UDP。TCP提供可靠的通信传输，而UDP则常被用于让广播和细节控制交给应用的通信传输。  
在IP首部中有一个协议字段，用来标识网络层的上一层所采用的是哪一种传输层协议。根据这个字段的协议号，就可以识别IP传输的数据部分究竟是TCP内容，还是UDP内容。同样传输层的TCP和UDP，为了识别自己所传输的数据部分究竟应该发送给哪个应用，也设定了一个这样的编号。以包裹传递为例，邮递员（IP）根据收件人的地址（目标IP地址）向目的地（计算机）投递包裹（IP数据报）。包裹到达目的地以后由对方（传输层协议）根据包裹信息判断最终的接收人（接收端应用程序）：  
![这里写图片描述][70]  
为了实现这一功能，使用端口号这样一种识别码。根据端口号就可以识别在传输层上一层的应用层中所要进行处理的具体程序。  
TCP/IP的众多应用协议大多以客户端/服务端的形式运行，例如对于HTTP连接请求：  
![这里写图片描述][70 1]  
这些服务端程序叫做守护进程。在unix中不需要将这些守护进程逐个启动，而是启动一个可以代表他们接收客户端请求的inetd服务程序即可。它是一种超级守护进程，该超级守护进程收到客户端请求以后会fork新的进程并且exec为sshd等各个守护进程。确认一个请求究竟发送给的是哪个服务端，可以通过所收到数据包的目标端口号轻松识别。

## 端口号 ##

数据链路和IP中的地址，分别指的是MAC地址和IP地址。前者用来识别同一链路中不同的计算机，后者用来识别TCP/IP网络中互联的主机和路由器。端口号用来识别同一台计算机中进行通信的不同应用程序。一台计算机上可以同时运行多个程序，传输层协议正是利用这些端口号识别本机中正在进行通信的应用程序。  
![这里写图片描述][70 2]  
仅凭端口号识别某一个通信是远远不够的，通常采用**“源IP地址”、“目标IP地址”、“协议号”、“源端口号”、“目标端口号”**这五个方面来识别一个通信，只要其中某一项不同，就被认为是不同的通信。  
![这里写图片描述][70 3]

**端口号的确定**

*  静态方法  
    标准既定的端口号。每个应用程序都有其指定的端口号，并不是可以随意指定任何一个端口号。每个端口号都有其对应的使用的目的。
 *  动态方法  
    时序分配方法。此时，服务端有必要确定监听端口号，但是接受服务的客户端没必要确定端口号。在这种方法下，客户端应用程序可以完全不用自己设置端口号，而全权交给操作系统进行分配。可以为每个应用程序分配互不冲突的端口号，即使是同一个客户端程序发起多个TCP连接，识别通信连接的数字也不会相同。  
    **note：**端口号由其使用的传输层协议决定。不同的传输协议可以使用相同的端口号。数据到达IP层后，会先检查IP首部中的协议号，再传给相应协议的模块。如果是TCP传给TCP模块、如果是UDP传给UDP模块去做端口号处理。此外，那些知名端口号与传输层协议无关，只要端口一致都将分配到同一个程序处理，例如：53号端口TCP与UDP中都用于DNS服务，80端口用于HTTP通信（只能用TCP，UDP的80没开）。

## UDP ##

UDP是不具有可靠性的数据报协议。UDP不提供复杂的控制机制，利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立刻按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况下，UDP也无法进行流量控制等避免网络拥塞的行为。此外，UDP不负责重发，甚至当出现包的到达顺序乱掉时也没有纠正功能，需要这些控制，就要交由采用UDP的应用程序去处理。类似于说什么听什么的机制。经常用于以下几个方面：  
1、包总量较少的通信（DNS、SNMP等）；2、视频、音频等多媒体通信（即时通信）；3、限定于LAN等特定网络中的应用通信；4、广播通信（广播、多播）

## TCP ##

TCP是面向连接的、可靠的流协议。TCP为提供可靠性传输，实行“顺序控制”或“重发控制”机制。此外，还具备“流控制”、“拥塞控制”、提高网络利用率等众多功能。根据TCP的这些机制，在IP这种无连接的网络上也能实现可靠性的通信。为了通过IP数据报实现可靠性传输，TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。

--------------------

一旦建立了连接，进行通信的应用程序只使用这个虚拟的通信线路发送和接收数据，就可以保障信息的传输。应用程序可以不用顾虑提供尽职服务的IP网络上可能发生的各种连接，依然可以转发数据。TCP则负责控制连接的建立、断开、保持管理工作。  
![这里写图片描述][70 4]

--------------------

**序列号与确认应答**  
在TCP中，当发送端的数据到达接收主机时，接收端主机会返回一个已收到消息的通知，这个消息叫做确认应答（ACK）。  
![正常传输][70 5]  
TCP通过ACK实现可靠的数据传输。当发送端将数据发出之后会等待对端的ACK。如果有，就说明数据已经成功发送，反之可能丢失。在一定时间内如果没有收到ACK，发送端就可以认为数据已经丢失，并进行重发，如下图：  
![数据包丢失][70 6]  
此时，还有另外一种情况，没有收到ACK并不一定意味着数据包丢失，可能是ACK在途中丢失，这种情况也会导致发送端认为数据没有收到而进行重发，如下所示：  
![这里写图片描述][70 7]  
此外，也可能因为一些其他的原因导致ACK延迟到达。此时，源主机只需要按照机制重发数据即可，但对于目标主机它会反复收到相同的数据，为了对上层提供可靠的传输，必须放弃重复的数据包。因此，需要使用序列号。  
序列号是按照顺序给发送数据的每一个字节都标上号码的编码。接收端查询接收数据TCP首部中的序列号和数据的长度，将自己下一步应该接收的序号作为确认应答返送回去。利用ACK和序列号，TCP可以实现可靠传输。  
![这里写图片描述][70 8]

**重发超时**  
重发超时是指在重发数据之前，等待确认应答到来的那个特定时间间隔。TCP要求不论处在何种网络环境下都要提高性能通信，无论网络拥堵情况发生何种变化，都要保持这一特性。为此，它在每次发包时都会计算往返时间及其偏差。将这个往返时间和偏差相加重发超时的时间，就是比这个总和要稍大一点的值。  
![这里写图片描述][70 9]  
数据被重发后还是收不到ACK，则进行再次发送。此时，等待确认应答的时间将会以2、4的指数函数增长。达到一定重发次数之后，任然没有收到ACK，就强制关闭连接。

**连接管理**  
TCP提供面向有连接的通信传输。面向有连接就是在数据通信开始之前先做好通信两端之间的准备工作。TCP连接是通过发送一个SYN作为请求建立连接并等待确认应答（三次握手）；此外，在通信结束时会进行断开连接的处理（FIN包）。  
![这里写图片描述][70 10]  
建立一个TCP连接需要发送三个包，这个过程就为三次握手。一个连接的建立与断开，正常过程至少需要来回发送七个包才能完成。  
在建立TCP连接的同时，也可以确定发送数据包的单位（MSS），即最大消息长度。最理想的情况是，最大消息长度正好是IP中不会被分片处理的最大数据长度。MSS是在三次握手的时候，在两端主机之间被计算得出，两端的主机在发出建立连接请求时，会在TCP首部中写入MSS选项，过程如下：  
![这里写图片描述][70 11]

**窗口控制**  
TCP是以一个段为单位，每发一个段进行一次ACK处理，这样的传输在包的往返时间越长的情况下性能越差。  
![这里写图片描述][70 12]  
为了解决上述问题，TCP使用窗口，即使在往返时间较长的情况下也可以控制网络性能。ACK处理不再是以每个分段，而是以更大的单位进行确认，转发时间将会被大幅度缩减。窗口大小就是指无需等待ACK而可以继续发送数据的最大值如下图窗口为4个段。  
![这里写图片描述][70 13]  
这个机制实现使用了大量的缓冲区，通过对对多个段同时进行ACK处理的功能。例如下图，在发送端主机等到ACK之前，必须在缓冲区中保留窗口中的数据。当如期收到了ACK之后，就可以把数据从缓冲区中清除。  
![这里写图片描述][70 14]

**窗口控制与重发控制**  
对于ACK未能返回的情况下，在没有使用窗口控制时是要进行重发的，但是使用了窗口控制，就可以如下图所示，某些ACK即便丢失也不用重发。  
![这里写图片描述][70 15]  
对于某个报文段丢失的情况。如下图所示，接收端主机如果收到一个自已应该接收的序号以外的数据时，会针对当前为止收到数据返回确认应答。当发送端主机连续三次收到一个确认应答，就会将其所对应的数据进行重发（高速重发机制）。  
![这里写图片描述][70 16]

**流控制**  
通过流控制可以让发送端根据接收端的实际接受能力控制发送的数据量。具体说，接收端主机向发送端主机通知自己可以接收数据的大小，于是发送端不会发送超过这个限度的数据。该大小限度就是窗口大小，窗口大小的值就是由接收端主机决定的。TCP首部中，专门有一个字段用来通知窗口大小。接收端主机通过这个字段通知发送端自己可以接收的缓冲区大小，这个字段值越大，吞吐量越高。当接收端的这个缓冲区一旦要溢出时，窗口大小就会被设置为一个较小的值，从而控制数据发送量。也就是，发送端主机根据接收端主机的指示，对发送数据的量进行控制。  
![这里写图片描述][70 17]

**拥塞控制**  
一般，计算机网络处在一个共享的环境。在通信开始不应该发送大量的数据，这样会导致整个网络瘫痪。为了防止该问题的出现，在通信一开始会通过一个叫做慢启动的算法得出数值，对发送数据量进行控制。慢启动过程如下：  
![这里写图片描述][70 18]  
为了在发送端调节所要发送数据的量，定义了拥塞窗口。在慢启动的时候，将这个拥塞窗口的值设为1MSS（有时可以设置为更大），之后每收到一次ACK，拥塞窗口的值就加1。在发送数据包时，将拥塞窗口的小于接收端主机通知的窗口大小作比较，然后选择其最小者。  
但是，随着包的每次往返，拥塞窗口也会以1、2、4等指数函数的增长，拥堵状况激增甚至导致网络拥塞的发生。为了防止这些，使用慢启动阀值，当超过这个阀值之后，每一次收到ACK，只允许按照**(一个数据段的字节数)^2/(拥塞窗口)**比例放大拥塞窗口。  
![这里写图片描述][70 19]  
TCP的通信开始时，没有设置相应的慢启动阀值。而是在超时重发时，才会设置为当时拥塞窗口一半的大小。而由重复确认应答进行高速重发控制时，慢启动阀值被设置为当时窗口大小的一半，然后将窗口大小设置为该慢启动阀值+3个数据段的大小，由于重复确认应答而触发的高速重发与超市重发的处理不同，重复确认应答机制要求至少3次确认应答后才会触发重发，相比后者网络的拥堵要轻一些。当TCP通信开始以后，网络吞吐量会逐渐上升，但是随着网络拥堵的发生吞吐量会急剧下降。于是再次进入吞吐量慢慢上升的过程。

**提高网络利用率的方法**

*  Nagle算法  
    该算法是指发送端即使还有数据，但如果这部分数据很少则进行延迟发送的一种机制。只有在条件1、已发送数据都已经收到ACK；2、可以发送最大段长度（MSS）的数据时；中满足任意一个时才会发送数据，如果都不满足就暂时等待一段时间再发送。根据这种算法网络利用率虽然可以提高，但是可能会某种程度上的延迟。
 *  延迟确认应答  
    接收数据的主机如果每一次都立刻回复ACK，可能会返回一个较小的窗口。因为，刚接收数据缓冲区已满。当发送端收到小窗口的通知以后，会以它为上限发送数据，又降低了网络利用率。因此，可以在收到数据之后延迟一段时间在返回ACK。具体有：  
    ![这里写图片描述][70 20]  
    TCP采用滑动窗口的控制机制，因此通常确认少回答一些也无妨。TCP文件传输中，大多以两个数据段返回一次ACK。  
    ![这里写图片描述][70 21]
 *  捎带应答  
    根据应用协议，发送出去的消息到达对端，对端进行处理以后，会返回一个回执。此时，TCP的ACK和回执数据可以通过一个包发送，这样可以使收发数据量减小。另外，接收数据以后如果立马返回ACK，就无法实现捎带应答。而是将所接收的数据传给应用处理生成返回数据以后再进行发送请求为止，必须一直等待ACK。所以，必须启用延迟确认应答在可以实现捎带应答。  
    ![这里写图片描述][70 22]

[70]: /images/20220521/29ccce3752ef4f9983d7a9dbcdcc3348.png
[70 1]: /images/20220521/ac7dfe8a5e234b42827bb2bcf51e0f12.png
[70 2]: /images/20220521/a4d4abbe65c94de8ae85113e86a3f2d6.png
[70 3]: /images/20220521/5957276faffd41b6b1e216f1305b5741.png
[70 4]: /images/20220521/982dabd2983d4f1abda049674770b34f.png
[70 5]: /images/20220521/65a052c15e89425793bc970a766ee310.png
[70 6]: /images/20220521/0d00edc4818b4822bc3a852655bb1fe0.png
[70 7]: /images/20220521/09f3d35d309440dfa7e156c8e17e266f.png
[70 8]: /images/20220521/515d044cb69c47e586d9bba9389b85a5.png
[70 9]: /images/20220521/26d1bb7ea24d43b8ae16c3f489aa182d.png
[70 10]: /images/20220521/ecffad9980a348768533c1240630830d.png
[70 11]: /images/20220521/feb68eff0260428ea922d5bea99501ab.png
[70 12]: /images/20220521/073cdfa92b4d4eb0a1c2f869160dee28.png
[70 13]: /images/20220521/aca630440c6b4a54aab21b8c5126d7de.png
[70 14]: /images/20220521/7e4fde7b1c6f4142a740321696aacb9d.png
[70 15]: /images/20220521/a36be3ee0ba04069ad0b91b7686e85e4.png
[70 16]: /images/20220521/6d83dad76eff4801811d915c8633ce99.png
[70 17]: /images/20220521/5a75a4cf3d5845b883ad4d7cf2227bc9.png
[70 18]: /images/20220521/e7c3fe1e928e44f7ae38af3fc54f7575.png
[70 19]: /images/20220521/804018f6a50841c4bfb25688583fd30c.png
[70 20]: /images/20220521/042906f7781f40be89d1a14a27e46fd4.png
[70 21]: /images/20220521/bf95944245a04ade81e788ab3b460c2f.png
[70 22]: /images/20220521/7cec8a294e8145739f081880e93ead4c.png