计算机网络原理之传输层 #

目录 #

韩立刚计算机网络：传输层 #

什么是传输层 #

传输层是 ISO OSI 协议的第四层协议，实现端到端的数据传输。该层是两台计算机经过网络进行数据通信时，第一个端到端的层次，具有缓冲作用。当网络层服务质量不能满足要求时，它将服务加以提高，以满足高层的要求；当网络层服务质量较好时，它只用很少的工作。传输层还可进行复用，即在一个网络连接上创建多个逻辑连接。

传输层在终端用户之间提供透明的数据传输，向上层提供可靠的数据传输服务。传输层在给定的链路上实现流量控制、分段 / 重组和差错控制。传输层中一些协议是面向链接的，这就意味着传输层能保持对分段的跟踪，并且重传那些失败的分段。传输层的任务是根据通信子网的特性，最佳的利用网络资源，为两个端系统的会话层之间，提供建立、维护和取消传输连接的功能，负责端到端的可靠数据传输。在这一层，信息传送的协议数据单元称为段或报文。

网络层只是根据网络地址将源结点发出的数据包传送到目的结点，而传输层则负责将数据可靠地传送到相应的端口。

传输层服务类型 #

传输层提供的服务可分为传输连接服务和数据传输服务。

• 传输连接服务：通常，对会话层要求的每个传输连接，传输层都要在网络层上建立相应的连接。
• 数据传输服务：强调提供面向连接的可靠服务（很晚 OSI 才开始制定无连接服务的有关标准），并提供流量控制、差错控制和序列控制，以实现两个终端系统间传输的报文无差错、无丢失、无重复、无乱序。

传输层基本功能 #

传输层既是 OSI 层模型中负责数据通信的最高层，又是面向网络通信的低三层和面向信息处理的高三层之间的中间层。该层弥补高层所要求的服务和网络层所提供的服务之间的差距，并向高层用户屏蔽通信子网的细节，使高层用户看到的只是在两个传输实体间的一条端到端的、可由用户控制和设定的、可靠的数据通路。

传输层提供了主机应用程序进程之间的端到端的服务，基本功能如下：

• 分割与重组数据
• 按端口号寻址
• 连接管理
• 差错控制和流量控制，纠错的功能

传输层要向会话层提供通信服务的可靠性，避免报文的出错、丢失、延迟时间紊乱、重复、乱序等差错。

传输层在 OSI 中的地位和作用 #

传输层是整个协议层次结构的核心，是惟一负责总体数据传输和控制的一层。

在 OSI 七层模型中传输层是负责数据通信的最高层，又是面向网络通信的低三层和面向信息处理的高三层之间的中间层。因为网络层不一定保证服务的可靠，而用户也不能直接对通信子网加以控制，因此在网络层之上，加一层即传输层以改善传输质量。

传输层利用网络层提供的服务，并通过传输层地址提供给高层用户传输数据的通信端口，使系统间高层资源的共享不必考虑数据通信方面和不可靠的数据传输方面的问题。它的主要功能是：对一个进行的对话或连接提供可靠的传输服务，在通向网络的单一物理连接上实现该连接的复用，在单一连接上提供端到端的序号与流量控制、差错控制及恢复等服务。

传输层存在的必要性：

对于网络用户来说，希望通信双方的主机能得到端到端的可靠通信服务。但是，网络层提供的分组传输服务往往是不可靠的。要保证数据既不丢失也不重复，传输层是必不可少的。

分布式进程通信 #

网络层及以下的各层实现了网络中主机之间的通信，但数据通信不是最终的目的；计算机网络最本质的活动是主机之间的进程通信，以实现网络服务功能；设置传输层的主要目的就是要实现分布式进程通信。

计算机网络最根本的目的是要实现网络环境中联网计算机之间的分布式进程通信，以实现各种网络服务功能。

网络环境中的进程通信 #

网络环境中分布式进程通信的特点：

• 计算机网络是分布在不同地理位置的多台独立的计算机系统的集合；
• “独立的计算机系统” 意味着连网的每一台计算机的操作与资源是由自己的操作系统所管理；
• 用户共享的网络资源及网络所能提供的服务功能最终是通过网络环境中的分布式进程通信来实现的；
• 网络环境中的进程通信与单机系统内部的进程通信的主要区别：网络中主机的高度自治性；
• 不同的主机系统之间，没有一个统一的高层操作系统进行全局控制、调度与管理；
• 网络中一台主机对其它主机的活动状态、位于其它主机系统中的各个进程状态、这些进程什么时间参与网络活动、希望与网络中哪一台主机的什么进程通信都一概无从知道。

网络环境中分布式进程通信需要解决：

• 进程命名与寻址方法
• 多重协议的识别
• 进程间相互作用的模式

网络环境中进程标识：

• 在一台计算机中，不同的进程用进程号或进程标识（process ID）惟一地标识出来；
• 网络环境中完整的进程标识应该是：本地主机地址 - 本地进程标识、远程主机地址 - 远程进程标识；
• 进程地址也叫做端口号（port number）

多重协议的识别：

• UNIX 操作系统的 TCP/IP 的传输层就有 TCP 协议和 UDP 协议；
• 网络环境中一个进程的全网惟一的标识需要一个三元组来表示：协议，本地地址，本地端口号。
• 网络环境中一个完整的进程通信标识需要一个五元组来表示：协议、本地地址、本地端口号、远地地址、远地端口号。
• 在 UNIX 操作系统中：三元组又叫做半相关 half-association 五元组叫做一个相关 association。

进程间相互作用模式：Client/Server 模型 #

Client/Server 模型的基本概念：

网络中计算机既为本地用户提供服务，也为网络的其它主机的用户提供服务；网络中计算机的硬件、软件与数据资源应该既是本地用户可以使用的资源，也是网络的其它主机的用户可以共享的资源；每一项网络服务都对应一个 “服务程序” 进程；“服务程序” 进程要为每一个获准的网络用户请求执行一组规定的动作，以满足用户网络资源共享的需要。

在 TCP/IP 协议体系中，进程间的相互作用采用客户 / 服务器 (Client/Server) 模型；客户与服务器分别表示相互通信的两个应用程序的进程；客户向服务器发出服务请求，服务器响应客户的请求，提供客户机所需要的网络服务；

为什么要采用客户 / 服务器模型？

网络资源分布的不均匀性。

• 网络资源分布的不均匀性表现在硬件、软件和数据等三个方面；
• 网络资源分布的不均匀性是客观存在的，同时也是网络应用系统设计者的设计思想的体现；
• “资源共享” 是因为网络不同结点之间在硬件配置、计算能力、存储能力，以及数据分布等方面存在着差距与不均匀性；
• 能力强、资源丰富的充当服务器，能力弱或需要某种资源的成为客户。

网络环境中进程通信的异步性。

• 不同主机系统中进程什么时间发出通信请求，希望和哪一台主机的哪一个进程通信，以及对方进程是否能接受通信请求是不确定的；
• 网络分布式进程之间不存在一个高层、全局性的调度与协调机制；
• 必须要建立一个机制，为准备通信的进程之间建立起连接，在进程交换数据的过程中维护连接，为数据交换提供同步等控制与协调功能。

进程通信中 Client/Server 模型实现方法：

• 客户 / 服务器模型的工作实质是 “请求驱动”；
• 在网络环境中，客户进程发出请求完全随机。
• 为了实现服务器的功能，在服务器的设计中要解决服务器的：并发请求处理能力、并发服务器的进程标识、服务器安全问题

解决服务器处理并发请求的基本方案：

• 并发服务器
• 重复服务器

并发服务器（concurrent server） #

• 并发服务器的核心是使用一个守护程序（daemon）；
• 守护程序在系统启动的时候随之启动，在没有客户的服务请求到达时，并发服务器处于等待状态；
• 一旦客户机的服务请求到达，服务器根据客户的服务请求的进程号，去激活相应的子进程，而服务器回到等待状态；
• 并发服务器叫做主服务器（master），把子服务器叫做从服务器（slave）；
• 主服务器必须拥有一个全网熟知的进程地址；
• 网络中的客户进程可以根据服务器进程的熟知地址，向服务器提出服务请求。

端口寻址 #

端口就是传输层服务访问点 TSAP，端口的作用就是让应用层的各种应用进程都能将其数据通过端口向下交付给传输层，以及让传输层知道应当将其报文段中的数据向上通过端口交付给应用层相应的进程。

为了区分网络应用程序，传输层将给应用程序提供端口，端口用一个 16 bit 端口号进行标识，每个需要访问的进程会被分配到一个且唯一的端口号，有效的端口号为 0～65535。端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程，在因特网中不同计算机的相同端口号是没有联系的。

Internet 编号指派机构（IANA）负责分配端口号，IANA 组织是负责分配多种地址的标准化团体，端口号有以下三种类型。

• 公认端口（端口 0～1023）：用于服务和应用程序，如 HTTP、SMTP/POP3 等。
• 已注册端口（端口 1024～49151）：分配给用户进程，而不是分配给公认端口。
• 动态或私有端口（端口 49152～65535）：也称临时端口。端口在应用程序一开始被动态分配给客户端应用，客户端很少使用动态或私有端口。

传输层的两个协议 #

传输层的功能是由操作系统提供负责实现的，传输层位于操作系统的协议栈。操作系统通过 socket（即套接字）向应用层提供接口，应用层的程序仅需使用 socket 套接字的接口即可完成网络通讯（应用层只管调用 socket 的接口，就可以委托给传操作系统的协议栈处理了）。即应用程序调用 socket（即套接字）库向把数据包发给操作系统的协议栈。

如下图，协议栈有两部分组成，即传输层和应用层两部分都在这里，协议栈的上半部分是传输层，这里还有两块，分别是负责用 TCP 协议收发数据的部分和负责用 UDP 协议收发数据的部分，它们会接受应用程序的委托执行收发数据的操作。下半部分是用 IP 协议控制网络包收发操作的网络层部分。

套接字是一台主机内应用层和运输层之间的接口，也是进程与计算机网络之间的接口。

套接字是建立在网络应用程序的可编程接口，开发者可用控制套接字在应用层端的一切，但对运输层的控制仅限于

• 选择运输层协议；
• 设定若干运输层参数，如最大缓存和最大报文段长度等。

TCP 和 UDP 的应用场景 #

网络中的计算机通信无外乎有以下两种情况：

• 要发送的内容多，需要将发送的内容分成多个数据包发送。
• 要发送的内容少，一个数据包就能发送全部内容。

针对这两种情况，在传输层有两个协议，TCP（Transmission Control Protocol 即传输控制协议）和 UDP（User Datagram Protocol 即用户数据报协议）。

面向连接、面向非连接服务 #

传输层根据各应用程序不同的协议分为面向连接和面向非连接的两种服务类型。

• 面向连接服务是当发送方必须与接收方进行连接时才进行数据传递，最后释放连接过程。传输层的 TCP（传输控制协议）为面向连接的协议，提供了进程之间的可靠传递。
• 非连接的传输服务，发送方无须连接直接进行数据传递。UDP（用户数据控制协议）为面向非连接的协议。提供进程之间高效的数据传递。

传输层通过在应用程序间建立一个会话，提供面向连接的定位服务，在传输数据之前，传输层连接准备好应用程序间的通信准备。这些应用程序通信的数据在会话中严格地被管理。

根据应用程序不同，传输层协议也各不相同。例如，网页浏览或电子邮件发送要求确保接收和显示信息的完整性，因此即使速度较慢但是需要通过建立连接才进行数据传递。当今越来越多的融合性网络，包括声音、视频、数据，在共同传输过程中，不同应用对传输层的协议的要求也各不相同。可根据应用程序数据的开销、实时性等特征，在此基础上选择满足应用要求的传输协议。

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

应用层协议很多，传输层就两个协议，如何使用传输层两个协议标识应用层协议呢？传输层协议加一个端口号来标识一个应用层协议，展示了传输层协议和应用层协议之间的关系。

一些常见的应用层协议和传输层协议，以及它们之间的关系：

• HTTP 默认使用 TCP 的 80 端口标识。
• FTP 默认使用 TCP 的 21 端口标识。
• SMTP 默认使用 TCP 的 25 端口标识。
• POP3 默认使用 TCP 的 110 端口。
• HTTPS 默认使用 TCP 的 443 端口。
• DNS 使用 UDP 的 53 端口。
• 远程桌面协议（RDP）默认使用 TCP 的 3389 端口。
• Telnet 使用 TCP 的 23 端口。
• Windows 访问共享资源使用 TCP 的 445 端口。
• 微软 SQL 数据库默认使用 TCP 的 1433 端口。
• mySQL 数据库默认使用 TCP 的 3306 端口。

服务和端口之间的关系 #

Windows 和 Linux 操作系统有些服务为本地计算机提供服务，有些服务为网络中的计算机提供服务。为网络中计算机提供服务的服务，一旦启动就会使用 TCP 或 UDP 的某个端口侦听客户端的请求。

关于安全 #

无论 TCP 还是 UDP 都没有直接提供任何加密机制。因特网界研发了 TCP 的加强版本，称为安全套接字（Secure Sockets Layer，SSL）。用 SSL 加强后的 TCP，提供了包括加密、数据完整性和端点鉴别等安全服务。

用户数据报协议 UDP #

UDP 协议的特点 #

• UDP 是无连接的，即发送数据之前不需要建立连接（当然发送数据结束时也没有连接可释放），因此减少了开销和发送数据之前的时延。
• UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表（这里面有许多参数），通信的两端不用保持连接，因此节省系统资源。
• UDP 是面向报文的，发送方的 UDP 对应用程序交下来的报文，在添加首部后就向下交付给网络层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。
• UDP 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。
• UDP 支持一对一、一对多、多对一和多对多的交互通信。
• UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

UDP 端口号 #

TCP/IP 协议族中用端口号来标识进程，端口号是在 0 到 65535 之间的整数；客户程序随机选取的临时端口号；每一种服务器程序被分配了确定的全局一致的熟知端口号，每一个客户进程都知道相应的服务器进程的熟知端口号。

UDP 使用的熟知端口号：

UDP 的首部格式 #

UDP 的首部包括四个字段，源端口、目标端口、长度和校验和，每个字段的长度是两个字节。伪首部包括：源地址、目的地址、UDP 数据长度、协议类型（0x11），协议类型就一个字节，但需要补一个字节的 0x0，构成 12 个字节。

• 源端口：16 比特，表明发送端地址。
• 目的端口：16 比特，表明接收端地址。
• 长度：16 比特，表明包括 UDP 头在内的数据段的总长度。
• 校验和：16 比特，该字段可选，不用时可置 0。

计算 UDP 检验和的例子：

UDP 的服务器进程与请求 #

基于 UDP 的服务器应用程序和 TCP 一样也被分配了公认端口或已注册的端口。当基于 UDP 协议的应用程序或进程运行时，它们就会接收与所分配端口相匹配的数据；当 UDP 收到用于某个端口的数据报时，它就会按照应用程序的端口号将数据发送到相应的应用程序。

UDP 客户端进程 #

UDP 客户端进程则是从动态可用端口中随机挑选一个端口号，用来作为会话的源端口，而目的端口通常都是分配给服务器进程的公认端口或已注册的端口。客户端选择源端口和目的端口，通信事务中的所有数据报文头都采用固定的端口对，对于从服务器到达客户端的数据来说，数据报头所含的源端口和目的端口进行了互换。

传输控制协议 TCP #

TCP 协议主要的特点 #

• TCP 是面向连接的传输层协议。这就是说，应用程序在使用 TCP 协议之前，必须 先建立 TCP 连接。在传送数据完毕后，必须释放已经建立的 TCP 连接。这就是说，应用 进程之间的通信好像在 “打电话”：通话前要先拨号建立连接，通话结束后要挂机释放连接。
• 每一条 TCP 连接只能有两个端点（endpoint），每一条 TCP 连接只能是点对点的 （一对一）。
• TCP 提供可靠交付的服务。也就是说，通过 TCP 连接传送的数据，无差错、不丢失、不重复、且按序发送。
• TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序把数据传送给 TCP 的缓存后，就可以做自己的事，而 TCP 在合适的时候把数据发送出去。在接收时，TCP 把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
• 面向字节流。TCP 中的 “流”（steam）指的是流入到进程或从进程流出的字节序列。

TCP 报文的首部格式 #

TCP 协议是能够实现数据分段传输、可靠传输、流量控制、网络拥塞避免等功能，因此 TCP 报文的首部要比 UDP 报文首部字段要多，并且首部长度不固定。

• 源端口和目的端口：各占 2 个字节，分别写入源端口号和目的端口号。和前面图所示的 UDP 的分用相似，TCP 的分用功能也是通过端口实现的。
• 序号：占 4 字节。序号范围是 [0，232-1]，共 232（即 4 294 967 296）个序号。序号增加到 232-1 后，下一个序号就又回到 0。TCP 是面向字节流的。在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。
• 确认号：占 4 字节，是期望收到对方下一个报文段的第一个数据字节的序号。
  • TCP 协议能够实现可靠传输，接收方收到几个数据包后，就会给发送方一个确认数据包，告诉发送方下一个数据包该发第多少个字节了。
  • 若确认号是 N，则表明：到序号 N-1 为止的所有数据都已正确收到。
• 数据偏移：占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。这个字段实际上是指出 TCP 报文段的首部长度。由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。但请注意，“数据偏移” 的单位为 4 字节，由于 4 位二进制数能够表示的最大十进制数字是 15，因此数据偏移的最大值是 60 字节，这也是 TCP 首部的最大长度，这也就意味着选项长度不能超过 40 字节。
• 保留：占 6 位，保留为今后使用，但目前应置为 0。
• 紧急：URG（URGent） 当 URG=l 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据），而不要按原来的排队顺序来传送。
• 确认：ACK（ACKnowlegment） 仅当 ACK=1 时确认号字段才有效。当 ACK=0 时，确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。‘
• 推送：PSH（PuSH） 当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。
• 复位：RST（ReSeT） 当 RST=l 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
• 同步：SYN（SYNchronization） 在连接建立时用来同步序号。当 SYN=1 而 ACK=0 时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN=1 和 ACK=1。因此，SYN 置为 1 就表示这是一个连接请求或连接接受报文。
• 终止：FIN（FINish 意思是 “完”、“终”） 用来释放一个连接。当 FIN=1 时，表明此报文段的发送方的数据己发送完毕，并要求释放传输连接。
• 窗口：占 2 字节。窗口值是 [0，216-1] 之间的整数。TCP 协议有流量控制功能，窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量（单位是字节）。
• 检验和：占 2 字节。检验和字段检验的范围包括首部和数据这两部分。和 UDP 用户数据报一样，在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。
• 紧急指针：占 2 字节。紧急指针仅在 URG=1 时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）。因此紧急指针指出了紧急数据的末尾在报文段中的位置。
• 选项：长度可变，最长可达 40 个字节。当没有使用选项时，TCP 的首部长度是 20 字节。TCP 最初只规定了一种选项，即最大报文段长度 MSS（Maximum Segment Size）。

可靠传输 #

TCP 可靠传输的实现 - 停止等待协议 #

连续 ARQ 协议和互动窗口协议 - 改进的停止等待协议 #

以字节为单位的滑动窗口技术详解 #

滑动窗口是面向字节流的，为了方便大家记住每个分组的序号，下面的讲解每一个分组就假设 100 个字节，为了方便画图表示，将分组进行编号简化表示，如图所示，不过你要记住，每一个分组的序号是多少。

改进的确认 - 选择确认（SACK） #

TCP 通信时，如果发送序列中间某个数据包丢失，TCP 会通过重传最后确认的分组后续的分组，这样原先已经正确传输的分组也可能重复发送，降低了 TCP 性能。为改善这种情况，发展出 SACK（Selective Acknowledgment，选择确认）技术，使 TCP 只重新发送丢失的包，不用发送后续所有的分组，而且提供相应机制使接收方能告诉发送方哪些数据丢失，哪些数据已经提前收到等。

选择性确认最多表示 4 个边界：

超时重传的时间调整 #

TCP 的发送方在规定的时间内没有收到确认就要重传己发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是 TCP 最复杂的问题之一。传输层的超时计时器的超时重传时间究竟应设置为多大呢？TCP 往返传输时间 （RTT） 的测量可以采用两种方法：

• TCP Timestamp 选项：TCP 时间戳选项可以用来精确的测量 RTT。发送方在发送报文段时把当前时钟的时间值放入时间戳字段，接收方在确认该报文段时把时间戳字段值复制到时间戳回送回答字段。 因此，发送方在收到确认报文后，可以准确地计算出 RTT 来。RTT = 当前时间 - 数据包中 Timestamp 选项的回显时间。

• 重传队列中数据包的 TCP 控制块：在 TCP 发送窗口中保存着发送而未被确认的数据包，数据包 skb 中的 TCP 控制块包含着一个变量， tcp_skb_cb when，记录了该数据包的第一次发送时间，当收到该数据包确认， 就可以计算 RTT，RTT = 当前时间 - when。这就意味着发送端收到一个确认，就能计算新 的 RTT。

RTT 调整：

超时计时器设置的超时重传时间 RTO：

流量控制 #

网络内存及带宽是有限的，当传输层发现此类资源过载时就会利用某些传输层协议要求减小数据流量，流量控制同时可以防止网络丢失分段及分段重传。当然，数据分段在网络中的分段很可能随时会发生错误或丢失，此时传输层能够通过重传保证所有数据的正确性和完整性。

拥塞控制 #

TCP 滑动窗口 #

TCP 采用滑动窗口控制管理数据队列发送，发送数据方不需要在应用层开始发送数据时就立刻发送数据，可以等待数据累积到一定数量后一并发送；接收方同样也可以等待接收的数据达到一定数量后一起发送确认。

滑动窗口顾名思义是指接收窗口的大小可以随着已经接收的数据量变化，在 TCP 会话中，窗口大小是动态协商的。收发两端的窗口不断滑动，因此这种协议又称为滑动窗口协议。

滑动窗口是一种数据流控制机制，允许发送端在向目标端发送一定数量的数据之后接收一个确认滑动窗口协议，是 TCP 使用的一种流量控制方法。TCP 允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不需要每次发一个分组就停下来等待确认，因此 TCP 可以加速数据的传输。

重传策略 #

TCP 协议提供了管理数据段丢失的方法，当数据在传输过程中发送丢失时，TCP 设计一种方法就是重新发送未确认的数据段。重传的基本是设立重传定时器，该定时器在开始发送数据的同时被启动，如果在定时器超时前收到确认数据段，定时器将被关闭，否则，就重传数据段。

大部分情况下，TCP 只确认相邻序列的数据段。当一个或多个数据段丢失时，只有确认已传输完成的数据段。例如，当接收序列号为 1200 到 2000 和 3000 到 4000 的数据段，那确认号为 1201。中间空白的数据段被认为没有收到。

重传策略的关键就是对定时器的设定。影响超时重传机制协议效率的一个关键参数是重传超时时间（Retransmission TimeOut，RTO）。

RTO 的值设置得过大过小都会对协议造成不利影响。如果 RTO 设置过大将会使发送端经过较长时间的等待才能发现报文段丢失，降低了连接数据传输的吞吐量；另一方面，若 RTO 过小，发送端尽管可以很快检测出报文段的丢失，但也可能将一些延迟大的报文段误认为是丢失，造成不必要的重传，浪费了网络资源。

因此，从上面看来，若在建立连接前，首先设计两点间的传输往返时间（Round Trip Time，RTT），则可根据 RTT 来设置一合适的 RTO。显然，在任何时刻连接的 RTT 都是随机的，无法预先知道。TCP 可以通过测量来获取当前 RTT 的一个估计值，并以该 RTT 估计值为基准来设置当前的 RTO。自适应重传算法的关键就在于对当前 RTT 的准确估计，以便适时调整 RTO。

拥塞控制的原理 #

滑动窗口协议的基本原理就是在任何时刻，发送方都能发送连续帧数据段，称为发送窗口；同时，接收方也可以连续接收多个帧数据段，称为接收窗口。

发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送但是还没有被确认的帧，或者是那些可以被发送的帧。

拥塞控制方法 - 慢开始和拥塞避免 #

慢启动（慢开始）“Slow Start”：TCP 在连接建立成功后在网络中产生大量数据包，由此网络中设备缓存会被耗尽，很容易发生网络拥塞。

所以新建立的连接并不在一开始就大量发送数据包，而是根据网络情况逐步增加每次发送的数据量，这样能够避免网络拥塞。

网络拥塞窗口（CWND）在新建立连接时，初始化为 1 个最大报文段（MSS）大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认时，CWND 就增加 1 个 MSS 大小。CWND 随着网络往返时间（Round Trip Time，RTT）呈指数级增长，本质上慢启动发送起点较低，之后发送速度一点也不慢。

在开始时，CWND 值为 1；经过 1 个 RTT 后，CWND 值为 1×2=2；经过 2 个 RTT 后，CWND 值为 2×2=4。如果带宽为 W，那么经过 RTT×lg2W 时间就可以占满带宽。当然 CWND 也不能一直这样增长下去，一定需要某些限制。TCP 使用慢启动门限（ssthresh）变量，当 CWND 超过该值后，慢启动过程结束，进入拥塞避免阶段。

对于大多数 TCP 实现来说，ssthresh 的值是 65 536（同样以字节计算）。拥塞避免的主要思想是加法增大，也就是 CWND 的值不再指数级往上升，转而利用增加值，此时当窗口中所有的报文段都被确认时，CWND 的大小加 1，CWND 的值就随着 RTT 开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢地增加调整到网络的最佳值。

拥塞控制方法 - 快重传和快恢复 #

发送窗口的上限 #

TCP 连接管理 #

使用套接字在传输层进行连接和收发数据：

首先，客户端的数据收发需要经过下面 4 个阶段：

• 创建套接字（创建套接字阶段）
• 用管道连接服务器端的套接字（连接阶段）
• 收发数据（收发阶段）
• 断开管道并删除套接字（断开阶段）

相对地，服务器是将阶段（2）改成了等待连接，具体如下：

• 创建套接字（创建套接字阶段）
• 将套接字设置为等待连接状态（等待连接阶段）
• 接受连接（接受连接阶段）
• 收发数据（收发阶段）
• 断开管道并删除套接字（断开阶段）

客户端的套接字具体工作流程：

TCP 的连接建立（TCP 的三次握手） #

请求建立 TCP 连接的数据包：

TCP 连接建立的数据包:

确认的确认:

TCP 连接建立的过程：

为了进行可靠的传输，要保证客户端与服务器之间的数据发送和接收的正常进行。

• 第一次握手：Client 什么都不能确认；Server 确认了 Client 发送正常。
• 第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己接收正常，Client 发送正常。
• 第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送接收正常。

为什么需要进行第三次握手？主要防止已失效的连接请求报文突然又传送到了服务器，从而产生错误，防止无效的连接占满服务器的可用资源。

TCP 连接释放（TCP 四次挥手） #

• 第一次挥手：Client 发送 Fin+Acknowledgement 给 Server 端，表示自己要断开连接，这个时候 client 端已经没有数据要发送了。
• 第二次挥手：Server 接收到 client 发送的断开请求连接，那么这个时候 Server 需要发送一个 Acknowledgement=1 用于确定客户请求断开的信息成功接收了；有时候这个过程也会和第三次握手进行合并，就像上面展示的一样。
• 第三次挥手：Server 如果所有的数据已经接收完毕。这个时候就会发送一个 Fin=1，而 Acknowledgement=0 用于表示 Server 端已经没有数据要发送了。需要关闭连接。
• 第四次挥手：Client 端需要发送一个 Acknowledgement=1 表示这个 Client 接收到了 Server 的关闭请求信息，这样一来双方的就都关闭了。

查看 TCP 连接释放的数据包：

来源文章 #

• 计算机网络原理笔记 精整理 第五章 传输层
• 传输层 - MBA 智库百科
• 传输层之一传输服务与传输连接 - MBA 智库文档