5.1 运输层
5.1.1 进程之间的通信
通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之间的通信。
运输层最重要的两个功能：
① 复用：发送方不同的应用进程都可以使用同一个运输层协议传送数据。
② 分用：接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
5.1.2 运输层的两个主要协议
运输层两个运输协议：
① 面向连接的传输控制协议 TCP (TCP 报文段)
TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。
② 无连接的用户数据报协议 UDP (UDP 用户数据报)
UDP 在传送数据之前不需要先建立连接。远程主机的运输层在收到 UDP 报文后，不需要给出任何确认。
使用 UDP 和 TCP 协议的各种应用和应用层协议如下图：
5.1.3 运输层的端口
（1）服务器使用的端口号
① 熟知端口号或系统端口号，数值 0~1023。这些端口号指派给 TCP/IP 最重要的一些应用程序。
② 登记端口号，数值 1024~49151。
（2）客户端使用的端口号
数值 49152~65535。这类端口号仅在客户进程运行时才动态选择，又称短暂端口号。
5.2 用户数据报协议 UDP
5.2.1 UDP 概述
1.UDP 的主要特点
（1）UDP 是无连接的。即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
（2）UDP 使用尽最大努力交付，即不保证可靠交付。因此主机不需要维持复杂的连接状态表。
（3）UDP 是面向报文的。发送方的 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。
（4）UDP 没有拥塞控制。因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。
（5）UDP 支持一对一、一对多、多对一和多对多的交互通信。
（6）UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。
5.2.2 UDP 的首部格式
用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段只有 8 个字节，由四个字段组成，每个字段的长度都是两个字节。各字段意义：
（1）源端口：源端口号。
（2）目的端口：目的端口号。
（3）长度：UDP 用户数据报的长度。
（4）检验和：检验 UDP 用户数据报在传输中是否有错，有错就丢弃。
当运输层从 IP 层收到 UDP 数据报时，就根据首部中的目的端口，把 UDP 数据报通过相应的端口，上交到对应的应用程序。若接收方 UDP 发现收到的报文中的目的端口号不正确，就丢弃该报文，并有网际控制报文协议 ICMP 发送“端口不可达”差错报文给发送方。
5.3 传输控制协议 TCP
5.3.1 TCP 最主要的特点
（1）TCP 是面向连接的运输层协议。应用程序在使用 TCP 协议之前，必须先建立 TCP 连接。在传送数据完毕后，必须释放已经建立的 TCP 连接。
（2）每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的。
（3）TCP 提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复，并且按序到达。
（4）TCP 提供全双工通信。TCP 允许通信双方的应用程序在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。
（5）面向字节流。TCP 中的“流”指的是流入进程或从进程流出的字节序列。
TCP 并不关心应用进程一次把多长的报文发送给 TCP 的缓存，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP 发送的报文长度是应用进程给出的)。如果应用进程传送到 TCP 缓存的数据块太长，TCP 就可以把它划分短一些再传送。如果应用进程一次只发来一个字节，TCP 也可以等待积累有足够多的字节后再构成报文段发送出去。
5.3.2 TCP 的连接
TCP 把连接做为最基本的抽象。TCP 连接的端点叫做套接字或插口。端口号拼接到 IP 地址即构成了套接字。
套接字 socket = {IP 地址：端口号}
每一条 TCP 连接唯一地被通信两端的两个端点(即两个套接字)所确定。
TCP 连接 ::= {socket1，socket2} = {(IP:port1),(IP:port2)}
5.4 可靠传输的工作原理
5.4.1 确认和重传机制
如图(a)，B 所发送的对 M1 的确认丢失了。A 中设置有一个超时计时器，当在超时重传时间内没有收到确认，并无法知道是自己发送的分组出错、丢失，或者是 B 发送的确认丢失了，因此 A 在超时计时器到期后就要重传 M1。
如图(b)，传输过程中并没有出现差错，但 B 对分组 M1 的确认迟到了。A 会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。B 仍然会收到重复的 M1，并且同样要丢弃重复的 M1，并重传确认分组。
使用上面的确认和重传机制，就可以在不可靠的传输网络上实现可靠的通信。上述的这种可靠传输协议常称为自动重传请求 ARQ。
5.5 TCP 报文段的首部格式
TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段。一个 TCP 报文段分为首部和数据两部分。
（1）源端口和目的端口：各占两个字节。
（2）序号：占 4 字节，序号范围是[0,2^23-1],共2^23(即4 294 967 296)个序号。在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值指的是本报文段所发送的数据的第一个字节的序号。例如，一报文段的序号字段值是 301，而携带的数据共有 100 字节。这表明：本报文段的数据的第一个字节的序号是 301，最后一个字节的序号是 400。
（3）确认号 ack。占 4 个字节。是期望收到对方下一个报文的第一个数据字节的序号。
若确认号为 N，则表明：到序号 N-1 为止的所有数据都已正确收到，于是在返回发送方的确认报文段中把确认号置为 N。
（4）数据偏移：占 4 位。指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。
（5）保留：占 6 位，保留为今后使用。
（6）紧急 URG：当 URG = 1，表示紧急指针字段有效，将告知系统此报文段中有紧急数据，应尽快传送。
（7）确认 ACK：仅当 ACK = 1时确认号字段才有效。当 ACK = 0时，确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
（8）推送 PSH：发送方把 PSH 置 1，并立即创建一个报文段发送出去。接收方 TCP 收到 PSH = 1的报文段，就尽快交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。
（9）复位 RST：当 RST = 1，表明 TCP 连接中出现严重差错，必须释放连接，然后再重新建立运输连接。RST 置 1还用来拒绝一个非法的数据段或拒绝打开一个连接。
（10）同步 SYN：在连接建立时用来同步序号。当 SYN = 1 而 ACK = 0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN = 1 和 ACK = 1.
（11）终止 FIN：用来释放一个连接。当 FIN = 1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。
（12）窗口：占 2 字节。指发送本报文段的一方的接收窗口。窗口字段明确指出了现在允许对方发送的数据量。
（13）检验和：占 2 字节。检验和字段检验的范围包括首部和数据这两部分。
（14）紧急指针：占 2 字节。紧急指针仅在 URG = 1时才有意义。
5.6 TCP 可靠传输的实现
因为 TCP 有超时重传机制、滑动窗口、确认 ACK 以及需在通信时建立连接，因此 TCP 的可靠传输能得到实现。
5.6.1 滑动窗口
TCP 的滑动窗口是以字节为单位。假定一下为 A 收到 B发来的确认报文段，其中窗口为 500 字节，表示 B 可接收的数据大小为500，确认号为 0，根据这个 A 就构造出自己的发送窗口，其中发送窗口大小为 500(根据 B 的接收窗口大小设定)，1~500 为可发送序号，501 以后为不可发送序号，如(a)所示：
现在再来看(b),其中1~ 200 为已发送并被确认的序号，201~ 400 为已发送未被确认的序号，401~ 700 为允许发送但尚未发送的序号，701 以后为不可发送的序号，现在 A 收到来自 B 的确认号报文段，确认号为 201，表示 200 之前的数据 B 已经全部收到，并且期待收到的下一个序号是 201。于是 A 发送了序号为 201~400的数据，但如果 B 只收到了序号为 202、203 的数据，而未收到 201 的数据(可能 201 的数据在传送中丢失或滞留在网络中的某处)，表明了数据没有按序到达，由于 B 只能对按序收到的数据中的最高序号给出确认，因此 B 发送的确认报文段中的确认号仍然是 201(即期望收到的序号)，而不是 202 或 203。
先假定 A 发送了 201~400 的全部数据，并且 B 也收到了这全部的数据，于是 B 给 A 的确认报文段中的确认号是 401，表示 B 已经收到了序号 401 之前的所有数据，此时 A 的窗口应该向前滑动 200 个序号。但从图中发现发送窗口只到 800，使得发送窗口缩小，原因是 B 的接收窗口缩小了，导致 A 的发送窗口减小。
再来看看(c)，如果 A 在继续发送完序号 401~800 的数据后，发送窗口内的序号都已用完，但还没有再收到确认，此时 A 就必须停止发送。当 A 在经过一段时间后(由超时计时器控制)就重传这部分数据。
发送方和接收方都设有缓存机制：
发送缓存：
（1）发送应用程序传送给发送方 TCP 准备发送的数据。
（2）TCP 已发送但尚未收到确认的数据。
发送窗口只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除。发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。
接收缓存：
（1）按序到达的，但尚未被接收应用程序读取的数据。
（2）未按序到达的数据。
滑动窗口总结：
（1）虽然 A 的发送窗口是根据 B 的接收窗口设置的。但在同一时刻， A 的发送窗口并不总是和 B 的接收窗口一样大。这是因为通过网络传送窗口值需要经历一定的时间滞后并且发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值。
（2）对于不按序到达的数据应临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
（3）TCP 要求接收方必须有累计确认的功能(即只对按序到达的最后一个序号进行确认)，这样可以减少传输的开销。但是需要注意的是，接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，从而浪费了网络资源。
（4）TCP 的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。
5.6.2 超时重传时间的选择
TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。于是对于重传时间的选择是 TCP 最复杂的问题之一。
5.7 TCP 的拥塞控制
拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
拥塞控制方法：
（1）慢开始
（2）拥塞避免
（3）快重传
（4）快恢复
1**.慢开始和拥塞避免**
发送方的发送窗口等于拥塞窗口，拥塞窗口的大小取决于网络的拥塞程度。
发送发控制拥塞窗口的原则：只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减小注入到网络中的分组数，以便缓解网络出现的拥塞。判断网络拥塞的依据就是出现超时。
慢开始算法：由小到大逐渐增大发送窗口。
拥塞窗口 cwnd 每次的增加量 = min(N，SMSS(发送方的最大报文段))
N：原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。
每经过一个传输轮次(一个传输轮次所经历的时间就是往返时间 RTT)，拥塞窗口就加倍。
慢开始指的是一开始设置的拥塞窗口 cwnd = 1，使得发送方在开始时只发送一个报文段，然后再逐渐增大 cwnd。实际过程中，发送方只要收到一个对新报文段的确认，其拥塞窗口 cwnd 就立即加 1，并立即发送新的报文段。
为了防止拥塞窗口 cwnd 增长过大引起网络拥塞，还需要设置一个慢开始门限 ssthresh 状态变量：
① 当 cwnd < ssthresh 时，使用慢开始算法。
② 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
③ 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。
由图可知：
（1）如传输轮次4，当达到门限 ssthresh 时，改用拥塞避免算法。
（2）如传输轮次12，由于发生了超时，发送方判断网络拥塞，于是修改门限值为 max(拥塞窗口/2,2)，并将拥塞窗口置为1。
（3）如果在传输轮次达到22时，发送方一连收到 3 个对同一个报文段的重复确认，则要使用快重传。快重传算法规定，发送方只要一连收到 3 个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传。并且发送方启动快恢复算法。
发送方窗口的上限值 = Min[接收方窗口，拥塞窗口]
5.8 TCP 的运输连接管理
TCP 连接有三个阶段：连接建立、数据传送、连接释放
5.8.1 TCP 的连接建立
TCP 建立连接的过程叫做握手，握手需要在客户端和服务器之间交换三个 TCP 报文段。
第一次握手：建立连接时，客户端发送 SYN 报文段(即 SYN = 1的报文段)和一个初始序号 seq = x到服务器，并进入 SYN_SENT 状态，等待服务器确认。
第二次握手：服务器收到 SYN 包，如同意建立连接，则向客户端发送确认。在确认报文段中将 SYN、ACK 置 1，确认号是 ack = x+1，同时自己也要选择一个初始序号 seq = y。
第三次握手：客户端收到服务器的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y+1，自己的序号 seq = x+1。此时，TCP连接已经建立，A 进入 ESTABLISHED(已建立连接)状态。
当服务器收到客户端的确认后，也进入 ESTABLISHED 状态。
为什么要采用三次握手，两次不行吗？
当客户端发起第一次连接请求后，由于网络滞留的原因导致服务器一直没有收到该请求而无法给客户端发送确认，客户端在超时重传后再次发起连接请求直到本次连接释放后，此时前一次握手到达，如果没有三次握手的话，服务器就会立即给客户端发送确认并建立连接。
由于客户端并没有发出建立连接的请求，因此不会理睬服务器的确认，也不会向服务器发送数据，但服务器却一直等待客户端发来数据，就这样服务器的资源就白白浪费了。
如果采用三次握手的办法，可以防止上述现象的发生。例如在刚才情况下，客户端不会向服务器的确认发出确认，服务器 由于收不到确认，就知道客户端并没有要求建立连接。
5.8.2 TCP 的连接释放
第一次握手：释放连接时，客户端将释放报文段首部的终止控制位 FIN 置 1，序号 seq = u，此时，客户端进入 FIN_wait-1(终止等待1)状态，等待 B 的确认。
第二次握手：服务器收到连接释放报文段后即发出确认，确认号为 ack = u+1，这个报文段的序号为 v，此时，服务器就进入 CLOSE-WAIT(关闭等待)状态。并且此时客户端到服务器的连接已经释放，然而服务器到客户端的连接还未关闭，也就是说若服务器要给客户端发送数据，客户端仍要接接收。
第三次握手：客户端收到服务器的确认后，就进入 FIN-WAIT-2(终止等待2)状态，等待服务器发出的连接释放报文段。这个报文段使 FIN = 1，确认号 ack = u+1，序号 seq = w，这时服务器就进入 LAST-ACK(最后确认)状态，等待客户端的确认。
第四次握手：客户端收到服务器的连接释放报文段后，必须对此发出确认，在确认报文段中把 ACK 置 1，确认号 ack = w+1，自己的序号是 seq = u+1。然后进入到 TIME-WAIT(时间等待)状态。此时TCP 连接还没有释放，必须经过时间等待计时器设置的时间 2MSL 后，客户端才进入 CLOSED 状态。
为什么要等待 2MSL 的时间？
（1）为了保证客户端发送的最后一个 ACK 报文段能够到达服务器。若这个报文段在传输过程中发生丢失，而服务器仍处于最后确认状态，等服务器的超时重传这个连接释放报文段后，由于客户端没有等待 2MSL 的时间，而是直接关闭连接，那么客户端就收不到这个连接释放报文段，因而也不会再发送一次确认报文段，那么服务器就无法进入 COLSED 状态。如果客户端等待了 2MSL 的时间，那么客户端就能收到这个重传的报文段，接着客户端重传这个确认，最后客户端和服务器都能正常的进入 CLOSED 状态。
（2）防止“已失效的连接请求报文段”出现在本连接中，客户端发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个心得连接中不会出现这种旧的连接请求报文段。
注意：三次握手时发送的 SYN 报文段和四次握手时发送的 FIN 报文段都不能携带数据，但都要消耗掉一个序号。