一、传输层的功能

1. 传输层提供进程和进程之间的逻辑通信。
2. 复用与分用
   复用指发送方不同的进程都可以使用同一个传输层的协议进行数据传输。
   分用指接收方的传输层接收到报文后能把数据送交给正确的进程。
3. 传输层对收到的报文进行差错检测
4. 传输层的两种协议:

• 面向连接的传输控制协议TCP
  传送数据之前必须建立连接，数据传送结束后要释放连接。不提供广播或多播服务。由于TCP要提供可靠的面向连接的传输服务，因此不可避免增加了许多开销：确认、流量控制、计时器及连接管理等。
  特点： 可靠、面向连接、时延大、适用于大文件。
• 无连接的用户数据报协议UDP
  传送数据之前不需要建立连接，收到UDP报文后也不需要给出任何确认。
  特点： 不可靠、无连接、时延小、适用于小文件。

二、传输层的寻址与端口

复用：应用层所有的应用进程都可以通过传输层再传输到网络层。
分用：传输层从网络层收到数据后交付指明的应用进程。

1. 端口

• 是传输层的SAP，标识主机中的应用进程。
• 是个逻辑端口/软件端口
• 端口号只有本地意义，在因特网中不同计算机的相同端口是没有联系的。
• 端口号长度为16bit，能标识65536个不同的端口号。

端口号按范围分:
i. 服务端使用的端口号

• 熟知端口号
  0~1023
  给TCP/IP最重要的一些应用程序，让所有用户都知道。

FTP——21
TELNET——23
SMTP——25
DNS——53
TFTP——69
HTTP——80
SNMP——161

• 登记端口号
  1024~49151
  为没有熟知端口号的应用程序使用的。

ii. 客户端使用的端口号
49152~65535
仅在客户进程运行时才动态选择的端口号。

套接字
在网络中采用发送方和接收方的套接字组合来识别端点，套接字唯一标识了网络中的一个主机和它上面的一个进程。套接字Socket=(主机IP地址，端口号)

三、UDP协议

1. UDP特点

UDP只在IP数据报服务之上增加了很少功能，即复用分用和差错检测功能。

1. UDP是无连接的，减少开销和发送数据之前的时延
2. UDP使用最大努力交付，即不保证可靠交付
3. UDP是面向报文的，适合一次性传输少量数据的网络应用

面向报文是指： UDP对应用层给的报文既不拆分也不合并。对报文的长度大小不作任何改变。
应用层给UDP多长的报文，UDP就照样发送，即一次发一个完整报文。

4. UDP无拥塞控制，适合很多实时应用。
5. UDP首部开销小，8B， TCP是20B

2. UDP首部格式

0-15： 16位源端口号 2B
如果不需要对方给你回复，可以不填（全0）
16-31： 16位目的端口号 2B
0-15： 16位UDP长度 2B
整个UDP数据长度，首部+数据
16-31： 16位UDP检验和 2B
检验整个UDP数据报是否有错，错就丢弃
分用时，找不到对应的端口号，就丢弃报文，并给发送方发送ICMP“端口不可达”差错报告报文。

3. UDP校验

伪首部
只有在计算校验和时才出现，不向下传送也不向上递交。
4B 源IP地址
4B 目的IP地址
1B 全0
1B 首部协议字段 （17：UDP的协议字段）
2B UDP长度（UDP首部8B + 数据部分长度，不包括伪首部）

校验过程：
在发送端

1. 填上伪首部
2. 全0填充检验和字段
3. 全0填充数据部分（UDP数据报要看成许多4B的字串接起来）
4. 伪首部+首部+数据部分采用二进制反码求和
5. 把和求反码填入检验和字段
6. 去掉伪首部，发送
   在接收端
7. 填上伪首部
8. 伪首部+首部+数据部分采用二进制反码求和
9. 结果全为1则无差错，否则丢弃数据报/交给应用层附上差错的警告。

四、TCP协议

1. TCP特点

1. TCP是面向连接（虚连接）的传输层协议。打call
2. 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的。
3. TCP提供可靠交付的服务，无差错、不丢失、不重复、按序到达。 可靠有序，不丢不重
4. TCP提供全双工通信。

发送缓存： 准备发送的数据&已发送但尚未收到确认的数据。
接收缓存： 按序到达但尚未被接收应用程序读取的数据&不按序到达的数据。

5. TCP面向字节流

流：流入到进程或从进程流出的字节队列。
TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字符流。

2. TCP报文段首部格式

• 源端口 2B
• 目的端口 2B
• 序号 4B
  在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，本字段表示本报文段所发送数据的第一个字节的序号。
• 确认号 4B
  期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N，则证明到序号N-1为止的所有数据都已正确收到。
• 数据偏移（首部长度） 4bit
  TCP报文段的数据起始处距离TCP报文段的起始处有多远，以4B为单位，即1个数值是4B。
• 保留
• 6个控制位
• 紧急位URG
  URG=1时，表明此报文段中有紧急数据，是高优先级的数据，应尽快传送，不用在缓存里排队，配合紧急指针字段使用。
• 确认位ACK
  ACK=1时确认号有效，在连接建立后所有传送的报文段都必须把ACK置为1.
• 推送位PSH
  PSH=1时，接收方尽快交付接收应用进程，不再等到缓存填满再向上交付。
• 复位RST
  RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立传输连接。
• 同步位SYN
  SYN=1时，表明是一个连接请求/连接接受报文。
• 终止位FIN
  FIN=1时，表明此报文段发送方数据已发完，要求释放连接。
• 窗口 2B
  指的是发送本报文段的一方的接收窗口，即现在允许对方发送的数据量。
• 检验和 2B
  检验首部+数据，检验时要加上12B伪首部，第四个字段为6.
• 紧急指针
  URG=1时才有意义，指出本报文段中紧急数据的字节数。
• 选项
  最大报文长度MSS、窗口扩大、时间戳、选择确认……

3. TCP连接管理

TCP连接的建立采用客户服务器方式，主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫服务器。

3.1 连接建立

假设运行在一台主机（客户）上的一个进程想与另一台主机（服务器）上的一个进程建立一条连接，客户应用进程首先通知客户TCP，他想建立一个与服务器上某个进程之间的连接，客户中的TCP会用以下步骤与服务器中的TCP建立一条TCP连接：

三次握手

ROUND 1:
客户端发送连接请求报文段，无应用层数据。
SYN=1， seq=x（随机）
ROUND 2：
服务器为该TCP连接分配缓存和变量，并向客户端返回确认报文段，允许连接，无应用层数据。
SYN=1，ACK=1， seq=y（随机），ack=x+1
ROUND 3：
客户端为该TCP连接分配缓存和变量，并向服务器端返回确认的确认，可以携带数据
SYN=0，ACK=1，seq=x+1, ack=y+1

洪泛攻击
从上面连接建立的过程可以看到，服务端和客户端分别在ROUND2 和 ROUND3分配了缓存和变量，这是导致洪泛攻击的原因。
SYN洪泛攻击发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该攻击者就部队其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。


解决办法
设置SYN cookie

3.2 数据传输

3.3 连接释放

参与一条TCP连接的两个进程中的任何一个都能终止该连接，连接结束后，主机中的“资源”（缓存和变量）将被释放。

四次挥手

ROUND1：
客户端发送连接释放报文段，停止发送数据，主动关闭TCP连接。
FIN=1，seq=u
ROUND2：
服务器端回送一个确认报文段，客户到服务器这个方向的连接就释放了——半关闭状态。
ACK=1,seq=v,ack=u+1
ROUND3：
服务器端发送完数据，就发出连接释放报文段，主动关闭TCP连接。
FIN=1,ACK=1,seq=w,ack=u+1
ROUND4：
客户端回送一个确认报文段，再等到时间等待计时器设置的2MSL（最长报文段寿命）后，连接彻底关闭。
ACK=1, seq=u+1, ack=w+1

3.4 TCP可靠传输

什么是可靠？
保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的。

TCP实现可靠传输的机制
1. 校验
与UDP一样，增加伪首部
2. 序号
一个字节占一个序号
序号字段指的是一个报文段第一个字节的序号
3. 确认
确认重传不分家，TCP的发送方在规定时间（重传时间）内没有收到确认就要重传已发送的报文段。 —— 超时重传
4. 重传
超时
由于网络环境的复杂性，重传时间如果设置得过短，会大大增加不必要的网络负荷，如果设置得过长，会使网络太空闲。 所以，如何确定重传时间呢？
TCP采用自适应算法，动态改变重传时间RTTs（加权平均往返时间）。

有没有更好的办法能提前知道数据是否丢失而快速重传，不用等到超时之后再进行重传呢？

有，那就是冗余ACK（冗余确认）
冗余确认
每当比期望序号大的失序报文段到达时，发送一个冗余ACK，指明下一个期待字节的序号。
发送方已发送1,2,3,4,5,报文段
接收方收到1，返回给1的确认（确认号为2的第一个字节）
接收方收到3，仍返回给1的确认（确认号为2的第一个字节）
接收方收到4，仍返回给1的确认（确认号为2的第一个字节）
接收方收到5，仍返回给1的确认（确认号为2的第一个字节）
发送方收到3个对于报文段1的冗余ACK，那么认为2报文段丢失，重传2号报文段。 ===> 快速重传

3.5 TCP流量控制

流量控制：让发送方慢点，要让接收方来得及接收

TCP利用滑动窗口机制实现流量控制。
在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，即接收窗口rwnd（接收方设置确认报文段的窗口字段来将rwnd通知给发送方），发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值。

若接收方给发送方的rwnd减小到0了，发送方就停止发送数据。

那什么时候这种状态能够得以改变呢？请看下面：
TCP为每一个连接设有一个持续计时器，只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。
若持续计时器设置的时间到期，就发送一个零窗口探测报文段。接收方收到探测报文段时会给出现在的窗口值。
若窗口仍然是0，那么发送方就重新设置持续计时器。

3.6 TCP拥塞控制

出现拥塞的条件：对资源需求的总和 大于 可用资源。

这里的资源指：带宽、交换结点当中的缓存、交换结点当中的处理机等

网络中有许多资源同时呈现供应不足，网络性能变坏，网络吞吐量将随输入负荷增大而下降

拥塞控制
防止过多的数据注入到网络中。 （全局性）

拥塞控制四种算法
学习这四种算法之前，有几个假定（只是为了讨论问题方便）：

1. 数据单方向传送，而另一个方向只传送确认
2. 接收方总是有足够大的缓存空间，因而发送窗口大小取决于拥塞程度

接收窗口
接收方根据接收缓存设置的值，并告知给发送方，反映接收方容量。
拥塞窗口
发送方根据自己估算的网络拥塞程度而设置的窗口值，反映网络当前容量。

慢开始&拥塞避免
拥塞窗口从1开始，每次变为原来的2倍。直到达到拥塞窗口门限值ssthresh时，每次增加1，开始进入拥塞避免。 当发生拥塞时，窗口大小直接变回1，新门限值ssthresh调整为发生拥塞时窗口大小的一半。 重复上述步骤。
快重传&快恢复
快重传是指发生拥塞导致丢包时，如果收到3个重复的确认，执行快重传算法。
快恢复是指，发生拥塞时，ssthresh调整为发生拥塞时窗口大小一半，拥塞窗口变为ssthresh，然后逐渐递增。避免了从1开始的慢开始步骤。

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/17813.html。