1.概述

• 计网体系结构中的物理层、数据链路层、网络层共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信
• 实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。
• 如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议
• 运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等），它使得应用进程看见的好像是两个运输层实体之间有一条端到端的逻辑通信信道。
• 根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP。

2.运输层端口号、复用与分用的概念

• 运行在计算机上的进程使用进程标识符PID来标志
• 因特网上的计算机并不是使用统一的操作系统，不同的操作系统又使用不同格式的进程标识符
• 为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识。
• TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程
  • 端口号使用16比特表示，取值范围0-65535
    • 熟知端口号：0-1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议。例如：FTP使用21/20，HTTP使用80，DNS使用53
    • 登记端口号：1024-49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，防止重复。
    • 短暂端口号：49152-65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号课供其他客户进程以后使用。
  • 端口号只有本地意义，在有因特网中，不同计算机中相同的端口号没有联系。

发送方的复用和接收方的分用

发送方的复用和接收方的分用

TCP/IP体系的应用层常用协议所使用的运输层熟知端口号

熟知端口号

3.UDP与TCP

4. TCP的流量控制

• 一般来说，我们总希望数据传输得快一些，但是如果发送方发数据发送的过快，接收方就可能来不及接收，就会造成数据的丢失。
• 流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收
• 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制
  • TCP接收方利用自己的接收窗口大小来限制发送方发送窗口的大小
  • TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文。

5. TCP的拥塞控制

• 某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，叫做拥塞（带宽、交换节点中的缓存和处理机等都是网络的资源）

• 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降（个人理解为堵车）
  TCP通过以下四种算法来进行拥塞控制

  
  
  四种拥塞控制算法

6.TCP超时重传时间的选择

image.png

7.TCP可靠传输的实现

• TCP基于以字节为单位的滑动窗口来实现可靠传输
  • 发送方在未收到接收方的确认时，可将发送窗口内还未发送的数据全部发送出去
  • 接收方只接受序号落入发送窗口内的数据
• 发送方的发送窗口并不总是和接收方的接收窗口一样大
  • 网络传送窗口值需要经历一定的时间之后，并且这个时间不确定
  • 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸
• 对于不按序到达的数据应如何处理，TCP并无明确规定
  • 如果接收方把不按序到达的数据一路丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据
  • TCP通常对不按序到达的数据是先临时存放在接收窗口中的，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程
• TCP要求接收方必须有累计确认和捎带确认机制，这样可以减少传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
  • 接收方不应过分推迟发送确认，会导致发送方不必要的超时重传
  • 稍待确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据
• TCP的通信的全双工通信。同心中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。

8.TCP的运输连接管理！！

• TCP是面向连接的协议，它基于运输连接来传送TCP报文段
• TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。
• TCP运输连接有以下三个阶段：
  1. 建立TCP连接（三报文握手）
  2. 数据传输
  3. 释放TCP连接（四报文挥手）
• TCP 的运输连接挂你就是使运输连接的建立和释放都能正常地进行

8.1TCP的连接建立

• TCP的连接建立要解决以下三个问题：
  1. 使TCP双方能够知道对方的存在
  2. 使TCP双方能够协商一些参数（如最大窗口值，是否使用窗口扩大选项和时间戳选项以及服务质量）
  3. 使TCP双方能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配

• TCP使用三报文握手建立连接

  
  
  三次握手
  • 第一次握手：客户发送TCP连接请求报文段，同时将状态设置为同步已发送（SYN-SENT）。TCP连接请求报文段首部中的同部位SYN被设置为1，表明这是一个TCP连接请求报文段，序号字段seq被设置了一个初始值x，作为TCP客户进程所选择的初始序号。SYN为1的报文段不能携带数据，但要消耗一个序号
  • 第二次握手：TCP服务器进程接收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态（SYV-REVD）。该报文段首部中的同部位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段。序号字段seq被设置一个初始值y，作为TCP服务器进程所选择的初始序号，确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号的确认。这个报文段也不能携带数据。
  • 第三次握手： TCP客户进程接收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已建立状态。该报文段首部中的确认位ACK被设置为1，表明这是一个普通的TCP确认报文段，序号字段seq被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，普通确认报文段可以携带数据，不携带数据的不消耗序号，确认号字段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认。TCP服务器进程收到该确认报文段后也进入连接已建立状态。可进行可靠数据传输
• 第三次握手是否多余？（不多余）
  若使用两次握手，当TCP连接请求报文段在某些网络节点长时间滞留，造成该报文段的超时重传，假设重传的报文段被TCP服务器进程正常接收，并完成了TCP连接、数据传输和连接取消的一整套流程之后，双方都处于关闭状态，这时第一次滞留在网络节点中的TCP连接请求报文段正常到达了服务器进程，导致服务器进程误认为这是TCP客户进程在请求连接，于是发送TCP连接请求的确认并进入连接已建立状态，而这个确认报文段不会被客户进程理会，造成服务器的资源浪费。
  
  两次握手错误实例

8.2TCP的连接释放

四报文挥手

• TCP使用四报文挥手释放连接
  • 第一次挥手：二者均处于连接已建立状态，TCP客户进程主动关闭TCP连接，TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态。该报文段首部中的终止位FIN和确认位ACK都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认。序号字段的值设置u，等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1。终止位FIN等于1的报文段即使不携带数据，也要消耗掉一个序号。确认号ack字段的值设置为v，等于TCP客户进程之前收到的数据的最后一个字节的序号加1
  • 第二次挥手：TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态。该报文段首部中的确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段。序号字段设置为v，等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1。确认号ack字段被设置为u+1，这是对TCP连接释放报文段的确认。TCP服务器进程这时应通知高层应用进程，TCP客户进程要断开连接。此时，从TCP客户进程到TCP服务器进程这个方向的连接就释放了。此时连接处于半关闭状态，TCP服务器进程如果还有数据要发送，TCP客户进程仍要接收。TCP客户进程收到TCP确认报文段后就进入终止等待2状态。等待TCP服务器进程发出的TCP连接释放报文段。
  • 第三次挥手：若使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就要通知其TCP服务器进程释放连接。TCP服务器进程发送TCP连接释放报文段并进入最后确认状态。该报文段首部中的终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认。这是假定序号seq字段为w，这是因为在半关闭状态下，服务器进程可能又发送了一些数据。确认号ack字段的值为u+1，这是对之前收到的TCP连接释放报文段的重复确认。
  • 第四次挥手：TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，进入时间等待状态。该报文段首部中的确认位ACK值被设置为1，表明这是一个普通的TCP确认报文段。序号字段设置为u+1，因为第一次挥手消耗了一个序号。确认号ack字段的值w+1，是对收到的TCP连接释放报文段的确认。TCP服务器进程收到该报文段后就进入关闭状态。而TCP客户进程还要经过2MSL后才能进入关闭状态。MSL（Maximum Segment Lifetime）最长报文段寿命，RFC793建议为2分钟
• 为什么不直接关闭，而是进入时间等待状态？是否有必要？
  若当TCP服务器进程发送了TCP连接释放报文段后，TCP客户进程立即进入关闭状态并发送普通TCP确认报文段，如果这个确认报文段丢失，则会导致TCP服务器进程对之前所发送的TCP连接释放报文段的超时重传，并仍处于最后确认状态。重传的TCP连接释放报文段到达TCP客户进程，由于其为关闭状态，因此不理睬该报文段，会导致TCP服务器进程反复重传TCP连接释放报文段，并一直处于最后确认状态而无法进入关闭状态。TCP客户进程的时间等待状态就是为了保证TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态。

9.TCP报文段的首部格式

• 为了实现可靠传输，TCP采用了面向字节流的方式
• 但TCP在发送数据时，是从发送缓存中去除一部分或全部字节并给其添加一个首部使之成为TCP报文段后发送
  • 一个TCP报文段由首部和数据载荷构成

  • TCP的全部功能都体现在他首部中各字段的作用

    
    
    TCP报文段的首部格式