计算机网络学习【入门】——（五）传输层

第五章 传输层
一、TCP和UDP的应用场景
TCP (Transmission Control Protocol)：传输控制协议
UDP (User Datagram Protocol)：用户数据报协议
1.TCP的应用场景
需要将要传输的文件分段、传输，服务器和客户端之间要确立一个会话，确保在发送数据过程中不能有丢失，如果丢了，客户端就要服务器再发一遍，建立一个可靠传输并且有流量控制功能。类似QQ传输文件、从网站下载文件，这一类通信就是使用TCP协议。
2.UDP的应用场景
一个数据包就能完成数据通信，不需要分段、不需要建立会话、不需要流量控制、是不可靠传输。类似域名解析、QQ聊天、屏幕广播，这一类通信就是使用UDP
3.常用指令
查看会话 netstat -n
  查看建立会话的进程 netstat -nb
  查看服务器上侦听的端口  netstat -an  
  测试到远程计算机某个端口是否打开  Telnet 192.168.80.100 3389
二、传输层协议和应用层协议之间的关系
用传输层协议+端口=应用层协议
 
图 1 传输层协议和应用层协议之间的关系
如图1，TCP协议加一个3389端口就是应用层的RDP协议，UDP协议加一个69端口就是应用层的TFTP协议。其中比较特殊的是DNS协议，DNS协议可通过TCP或UDP协议加53端口形成，但是绝大多数是使用UDP协议的，因此可以说DNS是使用UDP协议。
用传输层协议+端口=应用层协议
常见的应用层协议使用的端口
http=TCP+80
https=TCP+443
RDP=TCP+3389
ftp=TCP+21
共享文件夹=TCP+445
SMTP=TCP+25
POP3=TCP+110
telnet=TCP+23
SQL=TCP+1433
DNS=UDP+53
三、服务和应用层协议之间的关系
1. 服务使用TCP或UDP的端口侦听客户端请求
2. 客户端使用IP地址定位服务器 使用目标端口 定位服务
3. 可以在服务器网卡上设置只开放必要的端口 实现服务器的网络安全
 
图 2服务和应用层协议之间的关系
如图2，web服务器使用的协议是TCP，使用80端口，80端口作为侦听客户端的请求的作用，假设服务器的IP是101，客户端的IP是102，当102客户端要访问web服务器时，客户端发出数据请求，当web服务的端口侦听到客户端发出的请求是80端口时，服务器就将数据返回给客户端。
    这中间还需要通过网卡的配置，若要实现网络安全，可从服务器中入手，即将服务器的端口关闭，另一种方法即是在网卡中设置只开放必要的端口。
四、传输层功能和端口范围
1. 传输层功能：传输层为相互通信的应用进程提供了逻辑通信   
2. 传输层的端口
协议号    端口
TCP    6
UDP    17
IGMP    1
端口：0~65535
  熟知端口：数值一般为0~1023
  FTP:21
  TELNET:23
  SMTP:25
  DNS:53
  HTTP:80
  https：443
  RDP:3389
登记端口号，数值为1024~49151
客户端口号，数值为49152~65535
五、TCP和UDP详讲
1. UDP
(1) UDP 是无连接的，发送数据之前不需要建立连接，，因此减少了开销和发送数据之前的时延。
(2) UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
(3) UDP 是面向报文的。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。UDP 一次交付一个完整的报文。
(4) UDP 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很适合多媒体通信的要求。 
(5) UDP 支持一对一、一对多、多对一和多对多的交互通信。
(6) UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。
2. UDP首部
如图3，应用层的报文传输到运输层时，运输层会在UDP用户数据报的数据部分前加上UDP的首部然后再传输到IP层。
 
图 3 UDP首部格式
用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段很简单，只有 8 个字节。如图4。
 
图 4用户数据报的首部和伪首部格式
用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段有 8 个字节，由 4 个字段组成，每个字段都是 2 个字节。 在计算检验和时，临时把“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和。
当运输层从 IP 层收到 UDP 数据报时，就根据首部中的目的端口，把 UDP 数据报通过相应的端口，上交最后的终点——应用进程。注意，虽然在 UDP 之间的通信要用到其端口号，但由于 UDP 的通信是无连接的，因此不需要使用套接字。
 
图 5 UDP基于端口的分用
3. TCP协议概述
（1）TCP主要特点：
  ·TCP 是面向连接的运输层协议。
  ·每一条 TCP 连接只能有两个端点 (endpoint)，每一条 TCP 连接只能是点对点的（一对一）。 
  ·TCP 提供可靠交付的服务。
  ·TCP 提供全双工通信。
  ·面向字节流
      ·TCP 中的“流”(stream) 指的是流入或流出进程的字节序列。
      ·“面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。
（2）TCP提供可靠交付、面向字节流
A和B通信之前，先确保网络是通的，然后才能传。在通信过程中，TCP提供全双工通信，例如人与人之间在打电话聊天时，A在说的同时B要有一些回应，或者A说的不清楚时B要反馈一下信息给A，然后A再重复一遍，这样才能确保通信的质量。即A和B在通信时，既要A给B一些信息，又要B给A返回一些反馈信息。
4. TCP如何实现可靠传输
（1） 无差错情况下:
     使用停止等待协议
 
图 6使用停止等待协议无差错情况
如图6，A 发送分组 M1，发完就暂停发送，等待 B 的确认 (ACK)。B 收到了 M1 向 A 发送  ACK。A 在收到了对 M1 的确认后，就再发送下一个分组  M2。
（2）出现差错：
如图7，在接收方 B 会出现两种情况：
   a. B 接收 M1 时检测出了差错，就丢弃 M1，其他什么也不做（不通知 A 收到有差错的分组）。
   b. M1 在传输过程中丢失了，这时 B 当然什么都不知道，也什么都不做。
  在这两种情况下，B 都不会发送任何信息。
  如何保证 B 正确收到了 M1 呢？
解决方法：超时重传
  ·A 为每一个已发送的分组都设置了一个超时计时器。
  ·A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组 M2 。
 
图 7出现差错
（3）确认丢失和确认迟到
 
图 8确认丢失和确认迟到
确认丢失：
·若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内不能收到确认，但 A 并无法知道：是自己发送的分组出错、丢失了，或者 是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1。
·假定 B 又收到了重传的分组 M1。这时 B 应采取两个行动：
   ·第一，丢弃这个重复的分组 M1，不向上层交付。
   ·第二，向 A 发送确认。不能认为已经发送过确认就不再发送，因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认。
确认迟到：
·传输过程中没有出现差错，但 B 对分组 M1 的确认迟到了。
·A 会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。
·B 仍然会收到重复的 M1，并且同样要丢弃重复的 M1，并重传确认分组。
像上述的这种可靠传输协议常称为自动重传请求 ARQ  (Automatic Repeat reQuest)。意思是重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。
停止等待协议的优点就是简单，缺点是信道利用率太低。
（4）信道利用率
 
图 9 数据包在信道内传输
如图9所示，TD是A发数据包所用的时间，传所用的时间是t1，确认数据包的时间是t2（TA），RTT是数据包往返的时间，那么整个周期总时间是TD+RTT+TA，而发数据包的时间是TD，由此可看出数据包的时间很短，但是整个周期又很长，所以说信道利用率很低。
信道利用率U=TD/(TD+RTT+TA)
提高信道利用率的方法是：让数据包一直发，这样就能提高信道利用率了，也就是使用流水线传输。
（5）流水线传输
·为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输。
·流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地传送。
·由于信道上一直有数据不间断地传送，这种传输方式可获得很高的信道利用率。
 
图 10流水线传输
如图10，由于信道上一直有数据不间断地传送，这种传输方式可获得很高的信道利用率。
5.TCP报文段的首部格式
·TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段。
·一个 TCP 报文段分为首部和数据两部分，而 TCP 的全部功能都体现在它首部中各字段的作用。
·TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节。
 
图 11报文段的首部格式
（1）源端口和目的端口字段——各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。  
（2）序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。 
（3）确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。 
（4）数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）。  
（5）保留字段——占 6 位，保留为今后使用，但目前应置为 0。 
（6）紧急 URG——当 URG=1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。 
（7）确认 ACK——只有当 ACK=1 时确认号字段才有效。当 ACK=0 时，确认号无效。 
（8）推送 PSH (PuSH)——接收 TCP 收到 PSH=1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。  
（9）复位 RST (ReSeT)——当 RST=1时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。 
（10）同步 SYN——同步 SYN=1 表示这是一个连接请求或连接接受报文。 
（11）终止 FIN (FINish)——用来释放一个连接。FIN=1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。 
（12）窗口字段——占 2 字节，用来让对方设置发送窗口的依据，单位为字节。
（13）检验和——占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。
（14）紧急指针字段——占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。  
（15）选项字段——长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。
MSS (Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的TCP 报文段。所以，MSS是“TCP 报文段长度减去 TCP 首部长度”。
（16）填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。
六、TCP滑动窗口技术实现可靠传输
1. 以字节为单位的滑动窗口技术
·根据 B 给出的窗口值，A 构造出自己的发送窗口。
·发送窗口表示：在没有收到 B 的确认的情况下，A 可以连续把窗口内的数据都发送出去。 
·发送窗口里面的序号表示允许发送的序号。
·显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。
 
图 12A向B发送字节
如图，B给出的窗口值是20个字节，那么A就构造出20个字节的窗口，A的发送窗口位置不变，图示为A发送了11个字节，前面绿色的表示已经发出，也已经确认B已经收到，那么蓝色框里面表示的则是将要发送的字节，当框内的字节发送出去且B已经确认接收时就如下图所示，确认收到的字节变为绿色，即已接受到字节。在A发送和B接收的过程中，方框是不移动的，即是说A发出了3个字节后，不管B有没有收到，A仍继续发送，但是发送窗口仍然停留在那里直到窗口内所有的字节都发送完成。
2. 超时重传时间的选择
TCP每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。
新的RTTs=(1-a)*(旧的RTTs)+a*(新的RTT样本)
超时重传时间应略大于上面得出的加权平均往返时间RTTs。
RTT：往返时间。
RFC2988推荐的a值为1/8.
七、TCP流量控制
 
图 13 TCP流量控制
A和B通信，在建立会话前，B先发送确认号给A，比如B发送Ack=0  rwnd=10，这就表示B的接收窗口是10个字节，从0字节开始，然后A就会根据B的接收窗口来设定A的发送窗口，A的发送窗口为10。那么此时A开始传送字节，首先1和2字节发送完成了，3和4也发送完成了，而在此时，5和6在发的过程中丢了，那么此时B会给A发个确认，发送Ack=5 rwnd=8，这就提示了A需要重新发送5和5以后的字节，而这里的rwnd窗口变小了，那么A的发送窗口内是5-12字节，在这里，5和6丢了先不管，7-12都在A的发送窗口，因此它们也可以发出来。等7-12都发完了之后，5和6就会重发送，等5和6发送完成了后，B就重新发送确认给A，发送Ack=13  rwnd=2，此时因为rwnd变成了2，就提示A发送13和14两个字节。
发完后B就继续发确认数据包，发送Ack=15  rwnd=0，因为rwnd=0，所以此时之前已经发送接收完成的字节都被移出接收缓存区，这样就节省了B的接收缓存。然后就进行调整下一步的Ack和rwnd。
 
图 14 清除缓存
八、TCP拥塞避免
1.出现资源拥塞的条件：对资源需求的总和>可用资源
2.拥塞控制和流量控制的差别：
·拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
  ·流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制，它所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
3.拥塞控制所起的作用
 
图 15拥塞控制所起的作用
如图15，红色的线表示通过拥塞控制后网络传输过程中的理想状态，蓝色表示通过拥塞控制后网络传输过程中的实际状态，而绿色则表示没有拥塞控制时的状态，由图可看出，如果不实行拥塞控制，网络就有可能因为用户上网的资源需要求不够而导致吞吐量达到死锁，即吞吐量=0，此时能上网，但是网络特别慢，几乎没网。
4.慢开始
（1） 慢开始是用来确定网络的负载能力的。算法的思路是由小到大逐渐增大拥塞窗口数值。
（2）初始拥塞窗口 cwnd 设置：
     ·旧的规定：在刚刚开始发送报文段时，先把初始拥塞窗口cwnd 设置为 1 至 2 个发送方的最大报文段 SMSS (Sender Maximum Segment Size) 的数值。
     ·新的 RFC 5681 把初始拥塞窗口 cwnd 设置为不超过2至4个SMSS 的数值。
（3）慢开始门限 ssthresh（状态变量）：防止拥塞窗口cwnd 增长过大引起网络拥塞。
（4）拥塞窗口 cwnd  控制方法：在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个 SMSS 的数值。
·拥塞窗口 cwnd 每次的增加量 = min (N, SMSS)     
   ·其中 N 是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。
    ·不难看出，当 N < SMSS 时，拥塞窗口每次的增加量要小于 SMSS。
·用这样的方法逐步增大发送方的拥塞窗口 cwnd，可以使分组注入到网络的速率更加合理。
 
图 16慢开始算法图解
如图16，发送方每收到一个对新报文段的确认（重传的不算在内）就使 cwnd 加 1，然后逐渐加大。
（5）慢开始和拥塞避免算法的实现举例
 
图 17慢开始和拥塞避免算法
如图17，当 TCP 连接进行初始化时，将拥塞窗口置为 1。图中的窗口单位不使用字节而使用报文段。
    慢开始门限的初始值设置为 16 个报文段，即 ssthresh = 16。
    发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。
    在执行慢开始算法时，拥塞窗口 cwnd=1，发送第一个报文段。
    发送方每收到一个对新报文段的确认 ACK，就把拥塞窗口值加 1，然后开始下一轮的传输（请注意，横坐标是传输轮次，不是时间）。因此拥塞窗口 cwnd 随着传输轮次按指数规律增长。
    发送方每收到一个对新报文段的确认 ACK，就把拥塞窗口值加 1，然后开始下一轮的传输（请注意，横坐标是传输轮次，不是时间）。因此拥塞窗口 cwnd 随着传输轮次按指数规律增长。
    当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时（图中的点①，此时拥塞窗口 cwnd = 16），就改为执行拥塞避免算法，拥塞窗口按线性规律增长。
    当拥塞窗口 cwnd = 24 时，网络出现了超时（图中的点②），发送方判断为网络拥塞。于是调整门限值 ssthresh = cwnd / 2 = 12，同时设置拥塞窗口 cwnd = 1，进入慢开始阶段。
    按照慢开始算法，发送方每收到一个对新报文段的确认 ACK，就把拥塞窗口值加 1。当拥塞窗口 cwnd = ssthresh = 12 时（图中的点③，这是新的 ssthresh 值），改为执行拥塞避免算法，拥塞窗口按线性规律增大。
   当拥塞窗口 cwnd = 16 时（图中的点④），出现了一个新的情况，就是发送方一连收到 3 个对同一个报文段的重复确认（图中记为 3-ACK）。发送方改为执行快重传和快恢复算法。
（6）强调指出
  ·“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。
  ·“拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。
（7）快重传算法
  ·采用快重传 FR (Fast Retransmission) 算法可以让发送方尽早知道发生了个别报文段的丢失。
  ·快重传 算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
  ·发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。
  ·使用快重传可以使整个网络的吞吐量提高约20%。 
不难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。 
（8）快恢复算法
当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法 FR (Fast Recovery) 算法：
a.慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；
b.新拥塞窗口 cwnd = 慢开始门限 ssthresh ；
c.开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。
 
图 18快恢复算法实现
因此，如图18，在图的点④，发送方知道现在只是丢失了个别的报文段。于是不启动慢开始，而是执行快恢复算法。这时，发送方调整门限值 ssthresh = cwnd / 2 = 8，同时设置拥塞窗口 cwnd = ssthresh = 8（见图中的点⑤），并开始执行拥塞避免算法。
九、TCP传输连接管理
传输连接有三个阶段，即：连接建立、数据传送和连接释放。
TCP连接的建立都是采用客户服务器方式。
主动发起连接建立的应用进程叫做客户。
被动等待连接建立的应用进程叫做服务器。
1. TCP的连接建立 
TCP 建立连接的过程叫做握手。握手需要在客户和服务器之间交换三个 TCP 报文段。称之为三报文握手。采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误。
    如图19，A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x。
    B 的 TCP 收到连接请求报文段后，如同意，则发回确认。B 在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号 ack = x+1，自己选择的序号 seq = y。
    A 收到此报文段后向 B 给出确认，其 ACK = 1，确认号 ack = y+1。A 的 TCP 通知上层应用进程，连接已经建立。 
B 的 TCP 收到主机 A 的确认后，也通知其上层应用进程：TCP 连接已经建立。

 
图 19三报文握手建立TCP连接的各状态
2. TCP的连接释放
TCP 连接释放过程比较复杂。数据传输结束后，通信的双方都可释放连接。TCP 连接释放过程是四报文握手。 
 
图 20 TCP连接释放
如图20，数据传输结束后，通信的双方都可释放连接。现在 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的 FIN=1，其序号seq=u，等待 B 的确认。
    B发出确认，确认号 ack = u+1，而这个报文段自己的序号 seq=v。TCP 服务器进程通知高层应用进程。从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。B 若发送数据，A 仍要接收。
   若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。 
   A 收到连接释放报文段后，必须发出确认。 
   在确认报文段中 ACK=1，确认号 ack= w+1，自己的序号seq = u+1。 
为什么A必须等2MSL的时间？
    第一，为了保证 A 发送的最后一个 ACK 报文段能够到达 B。
    第二，防止 “已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
3. TCP 的有限状态机
TCP 的有限状态机可以更清晰地看出 TCP 连接的各种状态之间的关系。TCP 有限状态机的图中每一个方框都是 TCP 可能具有的状态。每个方框中的大写英文字符串是 TCP 标准所使用的 TCP 连接状态名。状态之间的箭头表示可能发生的状态变迁。
    如图21，箭头旁边的字，表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作。图中有三种不同的箭头：
粗实线箭头表示对客户进程的正常变迁。粗虚线箭头表示对服务器进程的正常变迁。细线箭头表示异常变迁。
 
图 21 TCP的有限状态机

 

（本文章仅为个人笔记，缺乏严谨性，未经允许请勿转载）