概述
计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。
但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。
如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。
运输层向高层用户屏蔽 了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等)，它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。
根据应用需求的不同， 因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP。
端口号、复用与分用的概念
在运输层中，端口号是一个重要的概念，它标识了不同的应用程序或进程，以便数据能够正确地传递到目标地址 。
复用和分用是运输层中的两个核心功能。
复用指的是将所有应用层的进程通过运输层传送到网络层，实现了不同应用进程之间的数据共享和传输。换句话说，发送方将多个应用程序的数据合并成一个数据包，然后通过运输层传递给接收方。
而分用则是在接收方将接收到的数据根据端口号进行分离，将数据正确地交付给对应的应用程序或进程。这样可以实现多应用程序同时进行网络通信的功能。
举例来说，当您在计算机上同时运行多个网络应用程序（如浏览器、邮件客户端等），每个应用程序都会通过运输层与网络进行通信。每个应用程序会被分配一个唯一的端口号，这样接收方就能够根据端口号将数据分发给正确的应用程序。这个过程就像是在邮寄信件时，信封上的地址确保信件能够准确地送达到收件人一样。
UDP和TCP的对比
| 用户数据报协议UDP(User Datagram Protocol) | 传输控制协议TCP(Transmission Control Protocol) |
|---|---|
| 无连接 | 面向连接 |
| 支持一对一,一对多,多对一和多对多交互通信 | 每一条TCP连接只能有两个端点EP，只能是一对一通信。 |
| 对应用层交付的报文直接打包 | 面向字节流 |
| 尽最大努力交付,也就是不可靠;不使用流量控制和拥塞控制。 | 可靠传输，使用流量控制和拥塞控制。 |
| 首部开销小，仅8字节 | 首部最小20字节,最大60字节 |
TCP的流量控制
一般来说，我们总是希望数据传输得更快一些。
-
但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。
所谓流量控制(flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
-
TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。
-
TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文。
TCP的拥塞控制
TCP拥塞控制是一种用于防止过量数据包引发网络拥堵的机制。在TCP的运行过程中，关键参数包括拥塞窗口（cwnd）和慢启动开始门限（ssthresh）。当TCP连接建立后，cwnd的大小被初始化为1个最大报文段的大小。
四种主要的算法分别是慢启动、拥塞避免、快重传和快恢复。
-
慢启动：这是发送数据的起始阶段，此阶段的cwnd（拥塞窗口）值会从1开始逐步增大，以便加快数据的发送速度。然而，为了防止网络拥塞，当cwnd的值超过慢启动开始门限（ssthresh）时，就会进入拥塞避免阶段。
-
拥塞避免：在这个阶段，cwnd的值增长的速度会明显减慢，仅为每经过一个往返时间就增加1，而不是加倍。这样可以让cwnd缓慢的增长，比慢启动要慢得多。这样做的目的是为了避免因为频繁的超时导致的传输效率降低。
-
快重传和快恢复：当接收方连续三次收到同一个序号的ACK时，直接将cwnd的大小设置为ssthresh的值，并进入到快恢复阶段。这样做的目的是为了避免因为频繁的超时导致的传输效率降低。
TCP超时重传时间的选择
TCP超时重传时间的选择是TCP最复杂的问题之一。TCP的下层是一个互联网环境，IP数据报所选择的路由变化很大，因此运输层的往返时间 (RTT) 的方差也很大。
若把超时重传时间设置得太短，可能引起很多报文段的不必要的重传，使网络负荷增大。而如果把超时重传时间设置得过长，又可能使网络的空闲时间增大，降低了传输效率。为了平衡这两方面的因素，TCP采用了一种自适应算法来记录一个报文段发出的时间以及收到相应的确认的时间，这两个时间的差值就是报文段的往返时间RTT。
除此之外，TCP保留了RTT的一个加权平均往返时间RTTS（这又称为平滑的往返时间）。当第一次测量到RTT样本时，RTTS值就取为所测量到的RTT样本值。此外，一旦发生超时事件（RTO往往大于两倍的RTT），TCP不仅会重传对应数据段，还会降低当前的数据发送速率，因为TCP会认为当前网络可能发生了拥塞。
TCP可靠传输的实现
TCP基于以字节为单位的滑动窗口来实现可靠传输。
-
发送方在未收到接收方的确认时， 可将发送窗口内还未发送的数据全部发送出去;
-
接收方只接收序号落入发送窗口内的数据;
虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。
-
网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
-
发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。
对于不按序到达的数据应如何处理，TCP并无明确规定。
-
如果接收方把不按序到达的数据一-律丢弃， 那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。
-
TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
-
接收方不应过分推迟发送确认， 否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。
TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]。
-
捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。
TCP的通信是全双工通信。 通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。
TCP的运输连接管理
TCP的连接建立
TCP连接建立的过程，也被称为“三次报文握手”，是TCP协议中非常重要的一个环节。这个过程可以简单地描述为：
-
客户端向服务器发送一个SYN（Synchronize Sequence Numbers，同步序列编号）报文段，其中包含一个随机的序列号X。此时客户端进入SYN_SENT（同步已发送）状态。
-
服务器收到客户端发来的SYN报文段后，会以自己的SYN（Y）和ACK（Acknowledgement，确认）应答报文段作为回应，其中也包含一个随机的序列号Y。此时服务器进入SYN_RCVD（同步已接收）状态。
-
客户端收到服务器发来的SYN+ACK报文段后，会向服务器发送一个ACK（确认）报文段，其中也包含一个自己的序列号X+1。此时客户端进入ESTABLISHED（已建立连接）状态。
当完成以上三个步骤后，TCP连接就成功建立了。这个过程中，客户端和服务器之间进行了多次交互，确保双方都能够正确地理解和处理对方发来的信息。虽然这个过程看起来有些繁琐，但它却是保证TCP可靠传输的重要基础之一。
面试题：用两次报文握手可以吗？会发生什么事情
TCP连接建立的标准过程是通过三次报文握手来完成的。这个过程的主要目的是防止历史连接的建立，减少双方不必要的资源开销，并且能帮助双方同步初始化序列号。如果仅进行两次报文握手，将无法防止历史连接的建立，这会造成双方资源的浪费，也无法可靠的同步双方序列号。
举例来说，如果在两次报文握手的过程中，客户端发送的SYN报文在网络堵塞了，重复发送多次SYN报文，那么服务器可能会误认为这是一个新的连接请求，并可能为此创建一个新的连接。这不仅会浪费服务器的资源，还可能在网络中引起混乱。
TCP的连接释放
TCP连接释放的过程，也被称为“四次报文挥手”，是TCP协议中非常重要的一个环节。这个过程可以简单地描述为：
-
某一方（假设是客户端）发送一个FIN（Finish，结束）报文段，其中包含一个序列号X，用来关闭客户端到服务器的数据传送。此时客户端进入FIN_WAIT_1（终止等待1）状态。
-
服务器收到客户端发来的FIN报文段后，会以自己的ACK（确认）应答报文段作为回应，其中也包含一个自己的序列号Y。此时服务器进入CLOSE_WAIT（关闭等待）状态，表示同意客户端关闭请求。
-
当服务器数据传输完毕时，会向客户端发送一个FIN报文段，其中包含一个序列号Z。此时服务器进入LAST_ACK（最后确认）状态。
-
客户端收到服务器发来的FIN报文段后，会向服务器发送一个ACK（确认）报文段，其中也包含一个自己的序列号X+1。此时客户端进入TIME_WAIT（时间等待）状态。需要过一段时间（通常为2MSL，最大报文段生存时间）之后，客户端才会进入到CLOSED（已关闭）状态。
当完成以上四个步骤后，TCP连接就成功释放了。这个过程中，客户端和服务器之间进行了多次交互，确保双方都能够正确地理解和处理对方发来的信息。虽然这个过程看起来有些繁琐，但它却是保证TCP可靠传输的重要基础之一。
面试题：三次报文挥手可以吗？五次呢？会发生什么事情
TCP连接释放的标准过程是通过四次报文挥手来完成的。这个过程的主要目的是确保双方都能够正确的关闭连接，避免数据丢失和连接混乱等问题。
如果仅进行三次报文挥手，将无法保证双方都完全关闭了连接。例如，当客户端发送了FIN报文段后，服务器可能还有数据需要传输给客户端，此时服务器会回复一个ACK报文段，但是客户端已经处于FIN_WAIT_2状态，无法再接收到这个ACK报文段，从而导致数据的丢失。
而如果进行五次报文挥手，则会造成不必要的延迟和资源浪费。因为在这个过程中，双方会多次发送无用的FIN和ACK报文段，而这些报文段并不会对连接的释放产生任何作用。
TCP报文段的首部格式
TCP报文段的首部格式是固定的，共20个字节。具体来说，首部包括以下字段：
-
源端口和目的端口：各占16位，表示发送和接收数据的端口号，范围是0~65525。
-
序号：32位，表示本报文段所发送的数据的第一个字节的序号。序号范围是 [0, 2^ {32}-1 ]，共 2^ {32} 个。
-
确认号：32位，期望收到对方下一个报文段的第一个数据字节的序号。
-
数据偏移（DOFF）：4位，表示TCP报文段的数据起始处距离TCP报文段的起始处有多远，也就是首部的长度。
-
保留：6位，目前尚未使用，置为0。
-
URG、ACK、PSH、RST、SYN、FIN等控制位：6位，表示TCP报文段的性质，如紧急、确认、推送等。
URG：表示紧急指针是否有效。如果URG=1，则表明紧急指针字段有效，它告诉系统此报文段中有紧急数据需要处理； ACK：表示确认号是否有效。如果ACK=1，则表明确认号字段有效，它告诉系统需要给对方回送一个确认包； PSH：表示是否需要立即将数据传输给应用层。如果PSH=1，则表明需要立即将数据传输给应用层； RST：表示是否需要重置连接。如果RST=1，则表明需要重置连接； SYN：表示是否需要建立连接。如果SYN=1，则表明需要建立连接； FIN：表示是否需要释放连接。如果FIN=1，则表明需要释放连接。
扫一扫
793
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
