传输层(Transport)

  • 传输层有两个协议
    • TCP (Transmission Control Protocol) 传输控制协议
    • UDP(User Datagram Protocol) 用户数据报协议

UDP一般用于实时场景

有些DNS可以用TCP 有的可以用UDP

UDP

  • UDP是无连接的 减少了建立和释放连接的开销

  • UDP尽最大能力交付 不保证可靠交付

    • 因此UDP不需要维护一些复杂的参数 首部只有8个字节（TCP的首部至少有20个字节）

  • UDP长度（Length）

    • 占16位 首部的长度+数据的长度

检验和

计算内容：伪首部+首部+数据

  • 伪首部只在计算检验和时起作用 不会传递给网络层

端口（Port）

  • UDP首部中端口是占用2字节
    • 可以推测出端口号的取值范围是 0 - 65535
  • 客户端的源端口是临时开启的随机端口
  • 防火墙可以设置开启关闭某些端口提高安全性
    • 比如可以在数据库的端口设置防火墙 只有通过内部间接的形式可以访问

常用指令

  • netstat-an:查看被占用的端口
  • netstat-anb:查看被占用的端口、占用端口的应用程序
  • telnet主机端口:查看是否可以访问主机的某个端口

TCP

TCP 的首部

数据偏移

  • 取值范围是0x0101 ~ 0x1111
  • 乘以4：首部长度 (Header Length )
  • 数据偏移算首部长度 首部长度为多少数据就往右边偏移了多少

    保留

  • 占6位 目前全为0
  • 有些资料保留位只有三位 标志字段占9位

TCP的一个细节

  • UDP的首部中有个16位的字段记录了整个UDP报文段的长度(首部+数据)
  • 但是,TCP的首部中仅仅有个4位的字段记录了TCP报文段的首部长度,并没有字段记录TCP报文段的数据长度
  • 分析
    • UDP首部中占16位的长度字段是冗余的,纯粹是为了保证首部是32bit对齐
    • TCP\UDP的数据长度,完全可以由IP数据包的首部推测出来
    • 传输层的数据长度=网络层的总长度-网络层的首部长度-传输层的首部长度

检验和

  • 检验和的计算内容： 伪首部+首部+数据
  • 伪首部：占用12个字节 只在计算检验和时起作用 不会传递给网络层

标志位（Flags）

  • URG（Urgent）
    • 当URG为1 时，紧急指针字段才有效，表明当前报文段中有紧急数据 应优先尽快传送
  • ACK (Acknowledgement )
    • 当ACK=1时，确认号字段才有效
  • PSH(Push)
  • RST(Reset)
    • 当RST=1时，表明连接中出现严重差错 必须释放连接 然后重新建立连接
  • SYN(Synchronization)
    • 当SYN = 1 时，ACK=0时，表明这是一个建立连接的请求
    • 如果对方同意建立连接 回复SYN = 1 ，ACK = 1
  • Fin（Finish）
    • 当Fin 为1 表明数据发送完毕 要释放连接

序号 确认号 窗口

序号(Sequence Number) seq
  • 占4字节
  • 首先 传输过程中的每一个字节都会有一个编号
  • 在建立连接后 序号代表的是 这一次传给对方的TCP数据部分的第一个字节的编号
  • 序号是告诉对方我现在发到哪里了
确认号(Acknowledgment Number)
  • 占4个字节
  • 在建立连接后 确认号代表期望对方下一次传过来的TCP数据部分的第一个字节的编号
  • 确认号是告诉发送方我已经收到多少。请接下来发送多少的
窗口(Window)
  • 占2个字节
  • 这个字段有流量控制功能 用于告知对方下一次允许发送的数据大小(字节为单位)

TCP的几个要点

  • 可靠传输 保证服务器传输时丢包也能把丢的包传到客户端
  • 流量控制
  • 拥塞控制
  • 连接管理
    • 建立连接
    • 释放连接

TCP可靠传输

停止等待ARQ协议
  • ARQ(Automatic Repeat-reQuest) 自动重传请求
连续ARQ协议+滑动窗口协议
SACK（选择性确认）
  • 在TCP通信过程中，如果发送序列中间某个数据包丢失 （比如 1，2，3，4，5中的3丢失掉）
  • TCP会通过重传最后确认的分组后续的分组（最后确认的是2 会重传3，4，5）
  • 这样原先已经正确传输的分组也可能重复发送（比如4，5） 降低了TCP性能

为了改善这种情况 发展出了SACK（Selective Acknowledgment 选择性确认）技术

  • 告诉发送方哪些数据丢失 哪些数据已经提前收到
  • 使TCP只重新发送丢失的包（比如3） 不用发送后续所有的分组（比如4，5）

SACK信息会放在TCP首部的选项部分

  • Kind:占1字节。值为5代表这是SACK选项
  • Length:占1字节。表明SACK选项一共占用多少字节
  • left Edge:占4字节,左边界
  • Right Edge:占4字节,右边界
  • 一对边界信息需要占用8个字节 由于TCP首部的选项部分最多40个字节 所以
    • SACK选项最多携带4组边界信息
    • SACK选项的最大占用字节数 = 4* 8 +2 = 34
question
  • 如果有个包重传了N次还是失败 会一直持续重传到成功吗
    • 取决于系统的设置 比如有些系统 重传五次未成功就会发送reset报文（RST）断开
  • 发送数据大小不足接收窗口的大小
    • 如果接收窗口最多能接收4个包
      • 但是发送方只发送了两个包
    • 接收方应该如何确定后面还有没有两个包
      • 等待一定时间后没有第三个包
      • 就会返回确认收到两个包给发送方
  • 为什么选择在传输层就将数据“大卸八块”分成多个段,而不是等到网络层再分片传递给数据链路层?
    • 因为可以提高重传的性能
    • 如果在传输层分片 那对于传输层而言发了很多的包 对方的传输层也会接收到这些包 如果发生丢包 对方的传输层能告诉发送方的传输层丢的是哪个包
    • 我们需要明确的是： 可靠传输是在传输层进行控制的
      • 如果在传输层不进行分段 那么一旦出现数据丢失 整个传输层的数据都需要进行重传
      • 如果在传输层分了段,一旦出现数据丟失,只需要重传丟失的那些段即可

TCP流量控制

  • 如果接收方的缓存区满了 发送方还在疯狂发送数据

    • 接收方只能把收到的数据包丢掉 大量的丢包会极大的浪费网络资源
    • 所以要进行流量控制

  • 什么是流量控制

    • 让发送方的发送速率不要太快 让接收方来得及接受处理 且为点对点

  • 原理

    • 通过确认报文中窗口字段来控制发送方的发送速率
    • 发送方的发送窗口大小不能超过接收方给出窗口大小
    • 当发送方收到接收窗口的大小为0时，发送方会停止发送数据

  • 有一种特殊情况

    • 一开始 接收方给发送方发送了0窗口的报文段
    • 后面 接收方又有了一些存储空间 给发送方发送的非0 窗口的报文段丢失了
    • 发送方的发送窗口一直为0 双方陷入僵局

  • 解决方案

    • 当发送方接收到0窗口通知，这时发送方停止发送报文
    • 并且同时开启一个定时器 隔一段时间就发个测试报文去主动询问接收方最新的窗口大小
    • 如果接受的窗口大小还是0 发送方就会停止发送数据

TCP拥塞控制

  • 拥塞控制
    • 防止过多的数据注入到网络中
    • 避免网络中的路由器或链路过载
  • 拥塞控制是一个全局性的过程
    • 涉及到所有的主机 路由器
    • 以及与降低网络传输性能有关的所有因素
    • 是大家一起努力的结果
  • 相比而言 流量控制是点对点通信的控制
方法

几个缩写

  • MSS(Maxinum Segment Size) ： 每个段最大的数据部分大小
    • 在建立连接时确定
  • rwnd(receive window)： 接收窗口大小
  • cwnd(congestion window): 拥塞窗口大小 根据网络状况调整
  • swnd(send window): 发送窗口
    • swnd = min(cwnd,rwnd)

方法：

  • 慢开始 (slow start 慢启动)
  • 拥塞避免 (congestion avoidance)
  • 快速重传 (fast retransmit)
  • 快速恢复 (fast recovery)
慢开始
  • cwnd 的初始值比较小 然后随着数据包被确认方确认(收到一个ACK)
    • cwnd 就会成倍增长
拥塞避免
  • ssthresh(slow start threshold)：慢开始阈值 cwnd打到阈值后 以线性方式增加
  • 拥塞避免(加法增大) ：拥塞窗口缓慢增大 以防止网络过早出现拥塞
  • 乘法减小：只要网络出现拥塞 减半sshresh 与此同时 执行慢开始算法 （cwnd又恢复到初始值）
  • 当网络频繁拥塞 sshresh 值就下降很快
快重传
  • 接收方
    • 每收到一个失序的分组后就立即发送一个重复确认
    • 这样发送方能够及时知道有分组没到到达
    • 而不需要等待自己发送数据时候才进行确认
  • 发送方
    • 只要连续收到三个重复确认(总共四个相同的确认) 就应当立即重传对方尚未收到的报文段
    • 而不必继续等待重传计时器到期后再重传
快恢复
  • 当发送方连续收到三个重复确认， 就执行乘法减小算法 把ssthresh减半
    • 这是为了预防网络发生拥塞
  • 由于发送方现在认为网络很可能没有发生拥塞
    • 因此 与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值
    • 而是把cwnd值设置为ssthresh 减半后的数值
    • 然后开始执行拥塞避免算法(“加法增大” ) 使拥塞窗口缓慢的线性增大
快重传+快恢复

发送窗口的最大值 ： swnd = min(cwnd，rwnd)

  • 当rwnd<cwnd时,是接收方的接收能力限制发送窗口的最大值
  • 当cwnd<rwnd时,则是网络的拥塞限制发送窗口的最大值

TCP连接管理

序号确认号深入理解

注意 ACK 代表的是标志位中的确认号字段有效 而ack是代表确认号

真正的序号是一个很大的值 这个值在建立连接时确定

连接过程：

具体分析
  • 基于相对值分析
    • 第一步的时候是客户端想要和服务器建立连接 SYN 为1 且ack seq为0
    • 第二步是服务端做出响应 这时ACK为1(0+1) 这时服务端第一次发送 seq也为0
    • 第三步ack为1(0+1) 第二步ack期望从1开始的数据 第三步要对这个期望做出响应 所以seq 为1 但是这时数据依然是0个字节
    • 第四步发送HTTP请求给服务器 这时TCP数据部分假设有k个字节的数据 ack这时是期望服务器发送的数据从1开始(因为上一次服务器发送的数据还是0) seq是因为上一次服务器期望的也是从1开始 所以seq的值也是1
    • 只有前两次SYN标志位为1
  • 服务端返回的5~8步
    • 第N个包的序号 是前面第N-1个包数据的总长度+1
    • 他们的ack是k+1 因为是相对于客户端而客户端发送的字节为k

  • 最后一步 确认
    • 客户端按照服务器端ack 所以seq为k+1
    • ack 是期望服务器发b1+b2+b3+b4+1编号开始的字节 (注意seq的意思是序号啊！所以是最后一个包的序号加上最后一个包的长度)

如果是原生的：

实际上 在上面的表格中 原生值减初始值就是相对值

建立连接—三次握手

  • CLOSED ： client 处于关闭状态
  • LISTEN ：server处于监听状态 等待client 连接
  • SYN-RCVD： 表示server 接收到了SYN报文， 当收到client的ACK报文时候 server进入到ESTABLISHED状态 表明收到了第一次握手
  • SYN-SENT：表示client 已经发送了SYN报文等待server进行第2次握手
  • ESTABLISHED：表示连接已经建立
前两次握手的特点
  • SYN都为1
  • 数据部分长度都为0
  • TCP头部的长度一般是32个字节
    • 固定头部 ： 20字节
    • 选项部分： 12字节
  • 双方会交换一些信息
    • 比如MSS ，是否支持SACK ，Window scale(窗口缩放系数 就是窗口的值✖️这个值 为窗口真正容纳大小)等
    • 这些数据都放在了TCP头部的选项部分
为什么要三次握手 两次不行吗
  • 主要目的：防止server端一直等待 造成资源浪费
  • 如果建立连接只需要两次握手 可能出现的情况
    • 假设 client 发送的第一个连接请求报文段 因为网络延迟的原因 在连接释放以后的某个时间才能到达server
    • 本来这个连接时早已失效的 但是server收到这个失效的请求后，会误认为是client 再次发送的一个新的连接请求
    • 这个时候server就会向client发出确认报文段 同意建立连接
    • 如果采用的不是三次握手 那么只要server发出确认 那么新的连接就建立了
    • 由于现在client并没有真正想连接服务器的意愿，因此不会理睬server的确认 也不会向server发送数据
    • 但是server却以为新的连接已经建立， 并且一直等待client发来数据 这样server的很多资源就白白浪费掉了
  • 如果采用三次握手的办法可以防止上述现象发生
    • 例如上述的情况 client 没有向server 的确认发出确认 server 由于收不到确认 server 就知道client 并没有要求建立连接
如果第三次握手失败了 会发生什么
  • 此时server的状态为SYN-RECV 若等不到client的ACK server会重新发送SYN+ACK 包
  • 如果server 多次重发SYN+ACK都等不到client 的ACK 就会发送RST包 强制关闭连接
释放连接—四次挥手
状态解读

  • FIN-WAIT-1：表示想主动关闭连接

    • 向对方发送了FIN报文 此时进入到FIN-WAIT-1 状态

  • CLOSE-WAIT：表示在等待关闭

    • 当对方发送FIN给自己， 自己会回应一个ACK报文给对方 此时则进入到CLOSE-WAIT状态
    • 在这个状态下 需要考虑自己是否还有数据要发送给对方 如果没有 发送FIN报文给对方

  • FIN-WAIT-2 :只要对方发送ACK确认后 主动方就会处于FIN-WAIT-2状态 然后等待对方发送FIN报文

  • CLOSING:一种比较罕见的例外状态

    • 表示你发送FIN报文后,并没有收到对方的ACK报文,反而却也收到了对方的FIN报文
    • 如果双方几乎在同时准备关闭连接的话,那么就出现了双方同时发送IN报文的情況,也即会出现 CLOSING状态
    • 表示双方都正在关闭连接

  • LAST-ACK：被动关闭的一方在发送FIN报文后 最后等待对方的ACK报文

    • 当收到了ACK报文后 就可以进入CLOSED 状态了

  • TIME-WAIT

    • 表示收到了对方的FIN报文了 并且发出了ACK报文 就等2MSL后即可进入CLOSED状态了
      • 如果FIN-WAIT-1状态下 收到了对方同时带FIN 标志和ACK标志的报文时
        • 可以直接进入到TIME-WAIT 状态 而无须经过FIN-WAIT-2状态
        • (如果同时受到了二次三次挥手合并 那么可以没有FIN-WAIT-2状态)

  • CLOSED ：关闭状态

由于有些状态的时间比较短暂 所以很难用netstat 的命令看到 比如SYN-RCVD，FIN-WAIT-1等

细节

  • TCP/IP 协议栈在设计上， 允许任何一方先发起断开请求， 上文演示的是client主动要求断开

  • client 发送ACK后 需要有个TIME-WAIT阶段来等待一段时间后 再真正关闭连接

    • 一般是等待两倍的MSL（Maximum Segment LifeTime，最大分段生存期）
    • MSL是TCP报文在Internet上的最长生存时间
    • 每个具体的TCP实现都必须选择一个确定的MSL值,RFC 1122建议是2分钟
    • 可以防止本次连接中产生的数据包误传到下一次的连接中(因为本次连接中的数据包都会在2MSL时间内消失了 这样就可以保证不会误传)

  • 如果client 发送ack之后马上释放了 然后又因为网络的原因 server没有收到client的ACK server就会重新发送FIN

    • 这个时候的情况是
      • client 没有任何响应 服务器在干等着 甚至多次重发FIN 会浪费资源
      • client 有个新的应用程序刚好分配了同一个端口号 新的应用程序收到server再次发送FIN后马上开始执行断开连接的操作（Server发送FIN是通过端口号） 然后这个新的应用程序可能是想和server建立连接
抓包
  • 有时候在使用抓包工具的时候 可能只会看到3次挥手
    • 这时其实是第2，3次挥手合并了

  • 当 server接收到 clientl的FIN时,如果 server后面也没有数据要发送给 client了
  • 这时,serveri就可以将第2、3次挥手合并,同时告诉 client两件事
    • 已经知道 client没有数据要发
    • server已经没有数据要发了

完整TCP流程

c

Supplements

区分长连接短连接

首先要判断是长连接还是短连接要知道为什么建立连接

  • 如果是客户端发完请求拿到数据后马上断开连接 那么就是短连接
  • 如果建立连接以后有很多次数据交互 那么就是长连接
    • 长连接释放时间根据需求

假设建立连接没有断开连接

并不是对网卡造成影响 而是在内存中的有socket对象 会对内存有影响

Socket

客户端的socket和服务器端的socket的连接是独立的 关闭等操作不会对其他造成影响

socket是一对一释放连接