计算机网络

1. 计算机网络-传输层

1.1 传输层介绍

1.1.1 传输层 Transport Layer

• 传输层（Transport Layer）在计算机网络中是互联网协议套件与开放系统互连（OSI）网络堆栈中协议的分层结构中的方法的一个概念划分。该层的协议为应用进程提供端到端的通信服务。它提供面向连接的数据流支持、可靠性、流量控制、多路复用等服务。

1.1.2 提供服务

（1）面向连接的通讯

• 提供了传输层的连接管理，连接的建立、数据的传输，维持和终止连接。

（2）相同次序交付

• 网络层通常不保证数据包到达顺序与发送顺序相同，但这往往是一个可取的特点。这通常是通过给报文段编号来完成的，接收者按次序将它们传给应用进程。

（3）可靠性

• 由于网络拥塞和错误，数据包可能在传输过程中丢失。通过检错码（如校验和），传输协议可以检查数据是否损坏，并通过向发送者传ACK或NACK消息确认正确接收。自动重发请求方案可用于重新传输丢失或损坏的数据。

（4）流量控制

• 有时必须控制两个节点之间的数据传输速率以阻止快速的发送者传输超出接收緩衝器所能承受的数据，造成缓冲区溢出。这也可以通过减少缓冲区不足来提高效率。

（5）拥塞避免

• 拥塞控制可以控制进入到电信网络的流量。

（6）多路复用

• 端口可以在单个节点上提供多个端点。每个计算机应用进程会监听它们自己的端口，这使得在同一时间可以使用多个网络服务。它是在TCP/IP模型中是传输层的一部分，但在OSI模型中属于会话层。

1.1.3 端口号

（1）端口介绍

• 在计算机网络中，端口包括逻辑端口与物理端口两种类型
  • 物理端口号是用于连接物理设备之间的接口，如交换机，路由器等接口
  • 逻辑端口号是指逻辑上用于区分不同服务的端口，表示一台计算机的特定进程所提供的服务，后文说的端口不特别讲，全是代表逻辑端口

（2）端口号范围

• 在TCP/IP模型中,TCP与UDP的端口号长度都为16位，即范围为\(0 至 65536\)

（3）端口号分类

一般来说：

• 公认端口（WellKnown Ports）

  • 0-1023：它们紧密绑定（binding）于一些服务。通常这些端口的通讯明确表明了某种服务的协议。例如：80端口实际上总是HTTP通讯。

• 注册端口（用户端口）（Registered Ports）

  • 1024-49151：它们一般不固定分配给某个服务。也就是说有许多服务绑定于这些端口，这些端口同样用于许多其它目的。例如：许多系统处理动态端口从1024左右开始。

• 动态/私有端口（Dynamicand/ Private Ports）

  • 49152-65535：理论上，不应为服务分配这些端口。实际上，机器通常从1024起分配动态端口。但也有例外：SUN的RPC端口从32768开始。

（4）常用对的服务端口号

• 21端口：FTP 文件传输服务
  22端口：SSH 远程连接服务
  23端口：TELNET 终端仿真服务
  25端口：SMTP 简单邮件传输服务
  53端口：DNS 域名解析服务
  80端口：HTTP 超文本传输服务
  443端口：HTTPS 加密的超文本传输服务

  3306端口：MYSQL数据库端口
  5432端口：postgresql数据库端口
  6379端口：Redis数据库端口
  8080端口：TCP服务端默认端口
  8888端口：Nginx服务器的端口
  9200端口：Elasticsearch服务器端口
  27017端口：mongoDB数据库默认端口

1.2 用户数据包协议 User Datagram Protocol,UDP

1.2.1 UDP介绍

（1）UDP介绍

• UDP是一个无连接且不可靠的面向数据报的一个传输层协议，在TCP/IP模型中，UDP为网络层与应用层提供了一个简单的接口，并对传输层单元首部加入了复用和数字校验字段

（2）UDP特点

• 不是面向连接的，开销相较于TCP会小
• 首部字段（8）少于TCP首部（20）。
• 没有拥塞控制。
• 尽最大努力交付，即不可靠交付。实际上对于一些即时的数据传输如多媒体视频，语音传输等，通常为了速率和时延的要求，能够容忍少量数据的丢失。
• 面向数据。对于应用层交付的数据，既不合并，也不拆分，直接交给网络层，如果数据长度过大，由网络层进行分组；面对你网络层交上来的数据，直接去除首部后就交给应用层

1.2.2 UDP的报文结构

（1）报文结构

• UDP首部共4个字段，每个字段占2个字节，共16个字节

• 

• 来源端口：发送端进程的端口号，因为UDP报文不需要应答，为可选项，不用可置为0

• 目的端口：接收端进程的端口号

• 报文长度：UDP报头和数据总共占用的长度。可能的最小长度是8字节，因为UDP报头已经占用了8字节。由于这个字段的存在，UDP报文总长不可能超过65535字节（包括8字节的报头，和65527字节的数据）。实际上通过IPv4协议传输时，由于IPv4的头部信息要占用20字节，因此数据长度不可能超过65507字节（65,535 ? 8字节UDP报头 ? 20字节IP头部）

• 校验和：校验和字段可以用于发现头部信息和数据中的传输错误。该字段在IPv4中是可选的，在IPv6中则是强制的。如果不使用校验和，该字段应被填充为全0

（2）校验和的计算

• 当UDP运行在IPv4之上时，为了能够计算校验和，需要在UDP数据包前添加一个“伪头部”。伪头部包括了IPv4头部中的一些信息，但它并不是发送IP数据包时使用的IP数据包的头部，而只是一个用来计算校验和而已

  

• 发送方：

  • 首先把校验和字段置0，将加入伪首部的UDP
  • 然后将UDP报文以16位为分组，如果数据部分不是偶数字节，则添加临时的1个全0的字节
  • 接下来按照分组的二进制反码计算所有分组的和，将和的反码写入校验和字段

• 接收方：

  • 首先把接收到的UDP报文添加伪首部
  • 以16位为分组，如果不是偶数字节，需要添加一个临时的全0字节
  • 按二进制反码计算分组的和，当结果全为1时证明无差错，否则表明有差错，直接丢弃

1.3 传输控制协议 Transmission Control Protocol，TCP

1.3.1 TCP介绍

• 传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793 定义

• TCP旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的，可能不可靠的数据报服务。 原则上，TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作

1.3.2 TCP数据包结构

• 数据包结构

  

• 来源连接端口（16位长）－识别发送连接端口

• 目的连接端口（16位长）－识别接收连接端口

• 序列号（seq，32位长）：代表本次发送的报文是第几号

  • 如果含有同步化标志（SYN），则此为最初的序列号；第一个数据比特的序列码为本序列号加一。
  • 如果没有同步化标志（SYN），则此为第一个数据比特的序列码。

• 确认号（ack，32位长）—期望收到的数据的开始序列号，即已经收到的数据的字节长度加1。

• 数据偏移（4位长）—以4字节为单位计算出的数据段开始地址的偏移值。

• 保留（3比特长）—须置0

• 标志符（9比特长）

  • NS—ECN-nonce。ECN显式拥塞通知（Explicit Congestion Notification）是对TCP的扩展，定义于RFC 3540（2003）。ECN允许拥塞控制的端对端通知而避免丢包。ECN为一项可选功能，如果底层网络设施支持，则可能被启用ECN的两个端点使用。在ECN成功协商的情况下，ECN感知路由器可以在IP头中设置一个标记来代替丢弃数据包，以标明阻塞即将发生。数据包的接收端回应发送端的表示，降低其传输速率，就如同在往常中检测到包丢失那样。
  • CWR—Congestion Window Reduced，定义于RFC 3168（2001）。
  • ECE—ECN-Echo有两种意思，取决于SYN标志的值，定义于RFC 3168（2001）。
  • URG—为1表示高优先级数据包，紧急指针字段有效。
  • ACK—为1表示确认号字段有效
  • PSH—为1表示是带有PUSH标志的数据，指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。
  • RST—为1表示出现严重差错。可能需要重新创建TCP连接。还可以用于拒绝非法的报文段和拒绝连接请求。
  • SYN—为1表示这是连接请求或是连接接受请求，用于创建连接和使顺序号同步
  • FIN—为1表示发送方没有数据要传输了，要求释放连接。

• 窗口（WIN，16位长）—表示从确认号开始，本报文的发送方可以接收的字节数，即接收窗口大小。用于流量控制。

• 校验和（Checksum，16位长）—对整个的TCP报文段，包括TCP头部和TCP数据，以16位字进行计算所得。这是一个强制性的字段。

  • TCP的16位的校验和（checksum）的计算和检验过程如下：发送者将TCP报文段的头部和数据部分的和计算出来，再对其求反码，就得到了校验和，然后将结果装入报文中传输。（这里用反码和的原因是这种方法的循环进位使校验和可以在16位、32位、64位等情况下的计算结果再叠加后相同）接收者在收到报文后再按相同的算法计算一次校验和。这里使用的反码使得接收者不用再将校验和字段保存起来后清零，而可以直接将报文段连同校验加总。如果计算结果是全部为一，那么就表示了报文的完整性和正确性。

    注意：TCP校验和也包括了96位的伪头部，其中有源地址、目的地址、协议以及TCP的长度。这可以避免报文被错误地路由

• 紧急指针（16位长）—本报文段中的紧急数据的最后一个字节的序号。

• 选项字段—最多40字节。每个选项的开始是1字节的kind字段，说明选项的类型。

  • 0：选项表结束（1字节）
  • 1：无操作（1字节）用于选项字段之间的字边界对齐。
  • 2：最大报文段长度（4字节，Maximum Segment Size，MSS）通常在创建连接而设置SYN标志的数据包中指明这个选项，指明本端所能接收的最大长度的报文段。通常将MSS设置为（MTU-40）字节，携带TCP报文段的IP数据报的长度就不会超过MTU（MTU最大长度为1518字节，最短为64字节），从而避免本机发生IP分片。只能出现在同步报文段中，否则将被忽略。
  • 3：窗口扩大因子（4字节，wscale），取值0-14。用来把TCP的窗口的值左移的位数，使窗口值乘倍。只能出现在同步报文段中，否则将被忽略。这是因为现在的TCP接收数据缓冲区（接收窗口）的长度通常大于65535字节。
  • 4：sackOK—发送端支持并同意使用SACK选项。
  • 5：SACK实际工作的选项。
  • 8：时间戳（10字节，TCP Timestamps Option，TSopt）
    • 发送端的时间戳（Timestamp Value field，TSval，4字节）
    • 时间戳回显应答（Timestamp Echo Reply field，TSecr，4字节）

1.3.3 TCP连接管理

（1）建立连接-三次握手

• 三次握手（Three-way Handshake）是在通信双方建立连接时为了确定对方能够正常接受与发送数据，同步连接双方的序列号和确认号与窗口大小信息，总共需要进行三次报文传送

• 三次握手不能确定一条线路一定是可靠的，但是可以确认它是可用的

  

1. 客户端通过向服务器端发送一个SYN来建立一个主动打开，作为三次握手的一部分。客户端把这段连接的序号设定为随机数A。（SYN = 1,ACK = 0）
2. 服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK的确认码应为A+1，SYN/ACK包本身又有一个随机产生的序号B。（SYN=1，ACK=1）
3. 最后，客户端再发送一个ACK。此时包的序号被设定为A+1，而ACK的确认码则为B+1（ACK = 1）。当服务端收到这个ACK的时候，就完成了三次握手，并进入了连接建立状态,进入ESTABLISHED状态
   • 需要三次的原因：如果使用两次传输，假如客户端发送的第一个请求连接报文因网络阻塞延时，服务端没有收到，客户端检测到超时后又发送了一次连接请求报文，正常连接，然后进行数据传输，最后终止连接；假如之前的报文因网络正常后，到达服务端，两次握手的机制会让服务器再次接受连接请求，但是客户端不会处理回应，造成不必要的错误与服务端的资源消耗

• 如果服务端果服务器端接到了客户端发的SYN后回了SYN-ACK后客户端掉线了，服务器端没有收到客户端回来的ACK，那么，这个连接处于一个中间状态，既没成功，也没失败。于是，服务器端如果在一定时间内没有收到的TCP会重发SYN-ACK。在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻倍，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s才知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s，TCP才会断开这个连接。

（2）资源使用-TCP连接池

• 主机收到一个TCP包时，用两端的IP地址与端口号来标识这个TCP包属于哪个session。使用一张表来存储所有的session，表中的每条称作Transmission Control Block（TCB），tcb结构的定义包括连接使用的源端口、目的端口、目的ip、序号、应答序号、对方窗口大小、己方窗口大小、tcp状态、tcp输入/输出队列、应用层输出队列、tcp的重传有关变量等。

• 服务器端的连接数量是无限的，只受内存的限制。客户端的连接数量，过去由于在发送第一个SYN到服务器之前需要先分配一个随机空闲的端口，这限制了客户端IP地址的对外发出连接的数量上限。从Linux 4.2开始，有了socket选项IP_BIND_ADDRESS_NO_PORT，它通知Linux内核不保留usingbind使用端口号为0时内部使用的临时端口（ephemeral port），在connect时会自动选择端口以组成独一无二的四元组（同一个客户端端口可用于连接不同的服务器套接字；同一个服务器端口可用于接受不同客户端套接字的连接）。

1.3.4 可靠数据传输

（1）序号与确认号

• 序号包含序号seq与确认号ack字段,TCP报文发送者称自己的字节流的编号为序号（sequence number），称接收到对方的字节流编号为确认号。TCP报文的接收者为了确保可靠性，在接收到一定数量的连续字节流后才发送确认。这是对TCP的一种扩展，称为选择确认（Selective Acknowledgement）。选择确认使得TCP接收者可以对乱序到达的数据块进行确认。每一个字节传输过后，SN号都会递增1。

• 通过使用序号和确认号，TCP层可以把收到的报文段中的字节按正确的顺序交付给应用层。序号是32位的无符号数，在它增大到\(2^{32}-1\)时，便会回绕到0。对于初始化序列号(ISN)的选择是TCP中关键的一个操作，它可以确保强壮性和安全性

  

（2）确认机制

• 当发送端发送数据到达目标主机时，目标主机便会返回一个确认号，以便告知发送端本主机已经接受到数据，这个消息叫做确认应答（ACK）
• 当接收端主机接受到多个重复序列的包时会丢弃重复包，但是必须对每个包进行确认回复
• 可以采用对多个字节一组，然后只需确认一次接受到改组字节数据的报文，来提高传输效率

（3）超时重传

• 超时重传：超时重传设估计的时间作为收到数据包的确认的超时上限（RTO，Retransmission TimeOut）。当发送了某个报文时，就会启动计时器，如果超过这个上限仍未收到确认包，发送方将重传这个数据包。每当发送方收到确认包后，会重置这个重传定时器，如果多次没有收到确认，便会终止连接，并向上层发送异常信息。

  

  • TCP超时重传机制-百度百科

（3）滑动窗口协议（Sliding Window Protocol）

• 滑动窗口协议用于网络传输时的流量控制，避免因接受端因为机器性能或者网络原因处理不了大量数据而导致无法接受发送方发送数据。

  

1. TCP建立连接的初始，B会告诉A自己的接收窗口大小，比如为‘20’：字节31-50为发送窗口。根据B给出窗口值，A构造自己的窗口

2. A发送11个字节后，发送窗口位置不变，B接收到了乱序的数据分组：

3. 只有当A成功发送了数据，即发送的数据得到了B的确认之后，才会移动滑动窗口离开已发送的数据；同时B则确认连续的数据分组，对于乱序的分组则先接收下来，避免网络重复传递：

3. A收到新的确认号，窗口向前滑动

• 所有的窗口大小字段保存在WIN字段中

• 这里面涉及到一种情况，如果B已经告诉A自己的缓冲区已满，于是A停止发送数据；等待一段时间后，B的缓冲区出现了富余，于是给A发送报文告诉A我的rwnd大小为400，但是这个报文不幸丢失了，于是就出现A等待B的通知||B等待A发送数据的死锁状态。为了处理这种问题，TCP引入了持续计时器（Persistence timer），当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍未0，则重设持续计时器，继续等待。

TCP滑动窗口协议解释

1.3.5 拥塞避免

（1）网络拥塞

• 由于网络设备发送的数据量已经超出设备的处理能力或者链路的容量，造成网络堵塞的现象
• 拥塞避免就是防止过多的数据送至网络，防止发生上述情况

（2）拥塞窗口

• 发送方会设置一个数值来限制自己发送数据的最大值，称为拥塞窗口cwnd
• 发送方的发送的数据量限制于于拥塞窗口与对方滑动窗口的最小值

（3）慢开始

• 主机开时发送数据时，如果立即将大量的数据注入到网络中，可能会出现网络的拥塞。
• 慢开始算法就是在主机刚开始发送数据的时候先探测一下网络的状况，如果网络状况良好，发送方每发送一次报文都能正确的接受确认报文段。那么就从小到大的增加拥塞窗口的大小，即增加拥塞窗口cwnd的大小
  • 一般来说开始会发送1-3个报文段的数据量（取决于报文段的大小），之后每接受到确认报文，便会将拥塞窗口大小*2

（4）拥塞避免

• 拥塞避免：是指为了防止拥塞窗口增长过快，如果增长到某个值时便会进入缓慢增长的状态；

  • 这个值称为慢启动开始门限(ssthresh)
  • 当cwnd < ssthresh,使用慢启动算法
  • 当cwnd > ssthresh,使用拥塞控制算法
  • 当cwnd = ssthresh，这两个算法都可以

• 无论是慢开始算法还是拥塞避免算法，只要判断网络出现拥塞，就要把慢启动开始门限(ssthresh)设置为发送窗口的一半（>=2），cwnd(拥塞窗口)设置为1，然后在使用慢启动算法，这样做的目的能迅速的减少主机向网络中传输数据，使发生拥塞的路由器能够把队列中堆积的分组处理完毕。拥塞窗口是按照线性的规律增长，比慢启动算法拥塞窗口增长块的多

（5）快重传

• 快重传算法：要求首先接收方收到一个失序的报文段后就立刻发出重复确认，而不要等待自己发送数据时才进行捎带确认
  • 比如接收方成功的接受了发送方发送来的M1、M2并且分别给发送了ACK，现在接收方没有收到M3，而接收到了M4，显然接收方不能确认M4，因为M4是失序的报文段。如果根据可靠性传输原理接收方什么都不做，但是按照快速重传算法，在收到M4、M5等报文段的时候，不断重复的向发送方发送M2的ACK,如果接收方一连收到三个重复的ACK,那么发送方不必等待重传计时器到期，由发送方尽早重传未被确认的报文段

（6）快恢复

• 当发送发连续接收到三个确认时，就执行乘法减小算法，把慢启动开始门限（ssthresh）减半，但是接下来并不执行慢开始算法,而是把拥塞窗口cwnd设置为ssthresh的一半， 然后执行拥塞避免算法，使拥塞窗口缓慢增大

1.3.6 终止连接

（1）终止连接过程-四次挥手

1. 客户端数据发送完成，则它向服务端发送连接释放请求。该请求只有报文头，头中携带的主要参数为：FIN=1，seq=u。此时，客户端将进入FIN-WAIT-1状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号

2. 服务器收到客户端连接释放报文，通知相应的高层应用进程，告诉它客户端向服务器这个方向的连接已经释放了。此时服务端进入了CLOSE-WAIT（关闭等待）状态，并向客户端发出连接释放的应答，其报文头包含：ACK=1，ack=u+1，seq=v

   客户端收到该应答后，进入FIN-WAIT-2状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）

   第二次挥手完成后，客户端到服务端方向的连接已经释放，服务端不会再接收客户端的数据，客户端也没有数据要发送了。但服务端到客户端方向的连接仍然存在，服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间

3. 服务端将最后的数据发送完毕后，就向客户端发送连接释放报文，其报文头包含：FIN=1，ack=u+1，由于在CLOS-WAIT状态，服务端很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认

4. 客户端收到服务器的连接释放报文后，向服务端发出确认应答，报文头：ACK=1，ack=w+1，seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。该状态会持续2MSL（最长报文段寿命）时间，这个期间TCP连接还未释放，若该时间段内没有服务端的重发请求的话，客户端就进入CLOSED状态，服务端只要收到了客户端发出的确认，立即进入CLOSED状态。就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些

（3）客户端最后还要等待2MSL的原因

• 第一：为了保证服务端能收到客户端的确认应答。若客户端发完确认应答后直接进入CLOSED状态，那么如果该应答丢失，服务端等待超时后就会重新发送连接释放请求，但此时客户端已经关闭了，不会作出任何响应，因此服务端就无法正常关闭。
• 第二：防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

（4）为什么是四次挥手？

• 关闭连接时，服务器收到客户端的FIN报文时，仅仅表示客户端不再发送数据了但是还能接收数据，并且服务端也未必全部数据都发送给对方了，所以服务端可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，服务端的ACK和FIN一般都会分开发送，从而导致多了一次。

TCP四次挥手参考

计算机网络-运输层

原文：https://www.cnblogs.com/nishoushun/p/12723417.html