7、传输层（计算机网络笔记）

一、传输层的功能

1.1 OSI和DoD模型

1

说明：在 TCP/IP协议栈中，传输层有两个协议 TCP和 UDP

• TCP（Transmission Control Protocol），传输控制协议，这是一种可靠安全的传输协议。一般如果一个文件在传输时需要分段，在需要使用此协议。此协议会建立一个会话，实现可靠传输。而且还有流量控制功能。可以使用命令netstat -nb查看会话。
• UDP（User Data Protocol），用户数据报协议。此协议一般用在文件只需要一个数据报就可以传输完的情况，不需要分段，不需要建立会话，也不需要流量控制，是一种不可靠的传输。可用于多播和广播。

1.2 传输层协议和应用层协议之间的关系

2

说明：常用的应用层协议使用的端口有 http=TCP+80、 https=TCP+443、 RDP=TCP+3389、 ftp=TCP+21、共享文件夹 =TCP+445、 SMTP=TCP+25、 PoP3=TCP+110、 telnet=TCP+23、 DNS=UDP+53。这里相关的服务与应用层协议之间的关系是一个侦听的关系。当数据被发送到接收端的时候，接收端相应启动的服务会进行侦听。服务使用 TCP或 UDP的端口侦听客户的请求，客户端使用 IP地址定位服务器，使用目标端口定位服务，可以在服务器网卡上设置只开放必要的端口，实现服务器的网络安全。一些命令：

• 查看服务侦听的端口netstat -anb
• 产看建立的会话netstat -n
• 查看建立会话的进程netstat -nb
• 测试连接远程计算机某个端口是否打开telnet 192.168.80.100 3389

1.3 传输层功能

为相互通信的应用进程提供了逻辑通信

3

说明：传输层为应用进程之间提供端到端的逻辑通信（但网络层是为主机之间提供逻辑通信），还要对收到的报文进行差错检测，提供面向连接和无连接的服务。

1.4 传输层的端口

4

说明：

• TCP的端口：使用一个16位端口号进行标志，具有本地意义，即端口号只是为了标志本计算机应用层中的各进程。在Internet中不同计算机的相同端口号是没有联系的。

分类：

• 熟知的端口，数值一般为0-1023

FTP:21
telnet:23
SMTP:25
PoP3:110
DNS:53
HTTP:80
https:443
RDP:3389

• 登记端口号，数值为1024-49151
• 客户端口号，数值为49152-65535，使用命令netstat -n | find "ESTABLISHED"

二、传输层协议UDP和TCP

2.1 UDP协议

2.1.1 主要特点

此协议是无连接的，即发送数据之前不需要建立连接；使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制；是面向报文的，没有拥塞控制，很适合多媒体通信的要求；支持一对一、一对多、多对一和多对多的交互通信；首部开销小，只有八个字节。域名解析就是使用此协议。

2.1.2 UDP协议

5

6

说明： UDP协议的首部如上图。其中长度是指 UDP用户数据报的长度。

2.2 TCP协议

2.2.1 概述

此协议是面向连接的传输层协议，每一条TCP连接只能有两个端点（endpoint），每一条TCP连接只能是点对点的（一对一），此协议提供可靠交付的服务，提供全双工通信，面向字节流。

2.2.2 TCP的连接

此协议把连接作为最基本的抽象，每一条TCP连接有两个端点，连接的端点不是主机，不是主机的IP地址，不是应用程序，也不是传输层的协议端口。TCP连接的端点叫做套接字（socket）。端口号拼接到IP地址即构成了套接字。socket=(IP：port)，每一条TCP连接唯一的被通信两端的两个端口（即两个套接字）所确定。

2.2.3 可靠传输原理

7

说明：在传输过程中如果无差错的情况则如图（ a），发送端发出一个包，接收端接收到之后反馈一个消息，让发送端发送第二个包，一次类推，直到数据发送完毕。这就是停止等待协议，因为如果接收端不反馈成功接收的消息，发送端是不会发送下一个数据报的。如果在传输过程中出现错误，则发送端需要等待，等待一个稍微大于往返时间（ RTT）的时间段，如果没收到接收端的反馈，则超时重传。

• 确认丢失和确认迟到
  

  

  8
  
  说明：当发送端发送一个数据后，接收端接收到了，但是反馈的数据报丢了，那么发送端则重新发送前面的数据（认为没有收到），此时发送端收到之后将其丢弃，再次发送反馈的数据。这种情况即确认丢失。而确认迟到是指在上面的情况中，反馈的消息不是丢失了，而是发送太慢，导致发送端以为丢失了，然后重传，于是接收端继续丢弃重复数据报，并发送一个反馈消息。

• 使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。这种可靠传输协议通常称为自动重传请求ARQ（Automatic Repeate reQuest）。ARQ标明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

• 信道利用率
  停止等待协议的优点是简单，但缺点是信道利用率太低。
  

  

  8
  
  说明：从图中我们可以看到发送的时间为Td，而一个往返的总时间为（Td+RTT+Ta）。所以信道利用率U=Td/(Td+RTT+Ta)太低。那如果要向提高信道利用率，可选的办法有提高Td，即流水线传输：
  
  

  9
  
  这种情况下，就是让发送端一直发送数据，不要等待。那么这种情况下如何实现可靠传输呢？

• 连续ARQ协议
  

  

  10
  
  说明：如上有12个数据报，而发送窗口为5标明每次可以连续发送5个数据报。发送5个数据报之后等待，此时如果收到第一个数据报的反馈信息，那么发送窗口向后移动，发送第六个数据报，依次类推。同时每接受到一个数据报的反馈消息，则此数据报就可以从缓存中删除了。当然这种方式在确认反馈消息的时候效率不高，可以使用累积确认。

• 累积确认
  接收方一般采用累计确认。优点是容易实现，信道利用率高；缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。累积确认就是在发送时，首先发送多个数据报，比如此时发送的五个数据报中，第三个数据报没有收到，此此时就会反馈给接收端已经收到第二个数据报的信息，而接收端则会从第三个数据报开始，进行重发（当然也包括第四个和第五个数据报，虽然它们是发送成功的）。

2.2.4 TCP报文段的首部格式

11

说明：在发送数据时，有时候数据需要分成很多段发送，比如第一段为 0、1、2、3、4这五个数据组成的一个段，而 序号就是指每一段数据中第一个小数据（即 0）在整个要发送的数据报中所占的位置（也是 0）。当这个数据段被接收端收到之后会发送一个 确认号，此时的确认号就是 5，即要求发送端发送序号为 5的数据段。 TCP的首部大多数情况为 20个字节，但是也有情况不是，而此时就需要使用 数据偏移（首部长度）表示从第几个字节开始为真正的数据部分了，首部最长是 60=（0xFF）*4个字节，这里的 0xFF即数据偏移能够表示的最大十六进制数。

• 标记位URG=1表示在传输数据报时不需要排队，不管缓存中有多少数据。
• 标记位ACK=0表示确认号是无效的（在接收数据后其值为1，但是如果还没有发送数据，那当然就是0）。
• 标记位SYN=1表示同步，也就是这个数据报的发送需要建立一个会话。
• 标志位PSH=1表示接收端在将接收到的数据组装的时候不排序。
• 标志位RST=1表示TCP会话出现了严重的问题，需要重新建立连接。比如我们对某个打开但是会没有完全打开时，点击关闭，则会出现这种情况。
• 标志位FIN=1表示数据传输已经完毕了，需要释放连接。

窗口占两个字节，比如此时有两个主机A、B。A在发送数据时可以缓存的字节为65530个字节，于是需要将这个窗口发送给B，看B的接收缓存是不是能够满足最大的窗口字节，需要统一。同样，当B向A发送数据时也需要统一窗口。
紧急指针只有在标志位URG=1的情况下才有作用，这表示TCP报文中数据部分中前面的多少个字节需要紧急处理。
选项中有很多信息，比如最大TCP报文的长度为多少个字节，是不是支持选择性确认SACK。如果不够四个字节则会进行填充，以达到四个字节。

2.2.5 TCP如何实现可靠传输

• 以字节为单位的滑动窗口技术
  
  

  12
  
  说明：首先注意发送窗口和接收窗口必须一致，这里使用前面讲到的停止等待协议。如果A向B发送数据，在不出错的情况下，比如将最前面的20个字节分成了三段，1~3、4~7、8~10、11~20进行发送，当B还没有收到相关数据时，A是不能发送第21个字节及之后的数据的，此时如果A没有收到B的反馈，则A缓存中的数据是不能删除的，窗口也是不能移动的，当B反馈确认号为8时，则A缓存中，之前的数据就可以删除了，发送第八个字节后的数据，同时A的窗口可以向后移动了，可以发送21~27的数据了，而B中就可以将1~7个字节提取出去了，缓存中就可以删除，同时B的窗口也会向后移动，依次类推。但是如果在传输过程中8~10这一段数据丢失了，其他段都接收到了，于是会通过前面讲的选择性确认SACK来告诉A哪一段缺失了，要求重发。注意，不是一收到数据就发送确认，而是发现接收的数据不是连续的才发送确认号。

2.2.6 超时重传时间的选择

TCP每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。

13

超时重传时间应略大于上面得出的加权平均往返时间 RTTs。 RFC2988推荐的 α值为 1/8。

2.2.7 TCP的流量控制

用于解决发送端和接收端处理数据能力不同的问题。比如A发送数据很快，但是B的处理能力有限，很快A发送的数据就将B的缓存占满了，不能再接收数据了，比如先进行一部分处理才能再次接收，于是B需要向A告知这一点，这就是流量控制。在传输数据的过程中会根据自己的处理能力实时反馈相应的窗口，如果不能处理数据，则将窗口设置为零，先处理一部分数据之后再反馈相关信息，当接收端表示能够继续接收数据了，于是向发送端发送新的窗口和确认号，但是这个反馈信息如果丢失了怎么办？这里发送端会定时的发送窗口测定的数据报来检查接收端的窗口。

2.2.8 TCP拥塞控制

• 出现资源拥塞的条件：对资源需求的综合大于可用资源。

• 拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

• 流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制，它所要做的就是抑制发送端发送数据的速率，以便使接收端来得急接收。

• 拥塞控制所起的作用
  

  

  14
  
  说明：比如此时网路中最大的处理能力为100M，但是现在各个主机不管，都向其发送数据，使得发送的数据达到500M，此时可能路由器忙不过来了，可能只能处理了10M的数据，或者还可能死机，导致吞吐量极大的降低，这就是拥塞。而TCP都会有一个拥塞控制的作用，一般如果发现网络较忙时，就会协调传输速度，可能此时发送了90M的数据，但是网络正确处理了85个，此时网络的吞吐量却是很高的。

• 慢开始和拥塞避免
  发送方维持拥塞窗口cwnd（congestion window）。发送放控制拥塞窗口的原则是：
  1、只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去
  2、只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
  慢开始算法的原理：
  

  

  15
  
  说明:可以看到开始的时候只是发送了一个数据报，之后慢慢的增加发送速度，当然每次都会检查网路传输的情况，在网络畅通的情况下才会增加发送速度，反之则降低发送速度。
  
  

  16
  
  说明：刚开始的时候速度增长是以2的倍数增加，当达到慢开始门限后，则是每次增加1的速度增加。当速度达到24时发现出现了拥塞，于是则要计算一个新的慢开始门限，即此时速度的一般12，如果还是拥塞，则继续计算新的慢开始门限，之后则又开始慢慢增长，同时注意，此时的慢开始门限就是12了，而不是最开始的16。
  注意：拥塞避免并非指完全能够避免拥塞。而是在说在拥塞避免阶段把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。这是最开始的拥塞控制方法，之后又出现了新的方法，即快重传和快恢复。

• 快重传和快恢复
  快重传：比如此时发送端向接收端发送了1、2、3、4、5这样一个数据段，但是在发送的过程中第三个数据丢失了，根据之前讲的累积确认，此时还是必须等到第4、5个数据接收到之后才发送确认号，但是要知道只要收到的数据为1、2、4，发送端就已经知道丢包了，于是此时会向发送端连续发送三个相同的确认号，让其发送第三个数据报，这就是快重传。
  快恢复：如上，丢失第三个数据报可能是因为拥塞，于是发送端会降低拥塞窗口，比如此时减小到了1，但是对于接收端发送的三个相同的确认号，此时却都收到了，这标明此时网络又是很好的，不再拥塞了，此时就不会向之前那样先指数再线性这样增长了，而是让拥塞窗口快速恢复到12，然后线性增长，这是相对慢开始来说的。
  

  

  17

• 发送窗口的实际上限值
  发送方的发送窗口的上限值应当取为接收方窗口和拥塞窗口这两个变量中较小的一个，即应按一下公式确定：
  发送窗口的上限值= Min{rwnd, cwnd}

2.2.9 TCP的运输连接管理

传输连接有三个阶段，即：连接建立、数据传送和连接释放。TCP连接的建立都是采用客户服务器方式。主动发起连接建立的应用进程叫客户（client），被动等待连接建立的应用进程叫做服务器（server）。

• 三次握手建立TCP连接
  

  

  18
  
  说明：建立连接个过程中首先客户端发送一个同步数据报，此时同步标记SYN=1，标志位ACK=0，序号seq=x。服务器接受到这样一个数据报之后就知道这是一个主动发起连接的数据报，此时服务器发送一个数据报，其中SYN=1，标志位ACK=1，序号seq=y，由服务器指定，确认号ack=x+1，让客户端发送第x+1个字节，接下来，客户端就再次发送确认数据报，此时就没有同步标记了。在前两次数据传输中已经足够确定网络是否畅通，那么为什么还要发第三次确认数据？这是因为当客户端发起请求，而这个请求可能在网路传输中传输较慢，一直没有到达服务器，于是客户端再次发出请求，而此时请求很快便到达，而此次会话在传输任务完成之后会话就断开了，然而，第一次发起的请求数据报在之后又被服务器接受到了，服务器以为这是客户端又发起的请求，于是就向客户端发出确认，然而可能此时客户端不需要建立连接，于是便不理睬这个确认，于是服务器就一直等待客户端的确认且发出数据，这样资源便被浪费了，这种情况多的时候服务器就可能宕机。而在三次握手方式中，服务器如果接受到第三次确认后，那么就人为自己发出的确认信息有用，于是就开始进行数据传输了，如果等了一段时间，没有等到第三次确认，那么就释放这个连接了。

• 三次握手建立TCP连接的各状态
  

  

  19
  
  说明：客户端发出第一次请求之后就变成了SYN-SENT状态，而服务器收到之前是LISTEN状态，收到之后变为SYN-RCVD状态，客户端收到反馈后，发出请求，状态变为ESTABLISHED，而服务器收到之后变为ESTABLISHED。

• TCP的连接释放
  

  

  20
  
  
  

  21
  
  
  

  22
  
  
  

  23
  
  说明：连接过程如上。

• 连接释放过程中的状态
  

  

  24
  
  说明：连接必须经过2MSL的时间才真正释放，因为最后一次客户端向服务器确认的数据可能会丢失，所以需要等待。