文章目录
[1.1应用层 -> 传输层](#1.1应用层 -> 传输层)
[1.2应用层 <- 传输层](#1.2应用层 <- 传输层)
[2.1传输层 -> 网络层](#2.1传输层 -> 网络层)
[2.2传输层 <- 网络层](#2.2传输层 <- 网络层)
[3.1传输层使用Internet Checksum](#3.1传输层使用Internet Checksum)
[4.3.2.1服务器内核查看SYN的目的端口 是在监听中后 回复SYN+ACK[seq=y, ack=x+1]](#4.3.2.1服务器内核查看SYN的目的端口 是在监听中后 回复SYN+ACK[seq=y, ack=x+1])
一、协议层间的数据传输
除应用层外，到了传输层与网络层 都有隔开单位地独自处理
1.应用层与传输层
1.1应用层 -> 传输层
1.1.1TCP
应用层有连续有序的字节 就可以向TCP流动传的数据 TCP选择切装进每个报文里面 再分开单独处理 且保持应用层写入数据的流动
1.1.2UDP
应用层向UDP每波次传的数据 UDP都会分别装放在****每个完整的报文单位里面 分开单独处理 且保留应用层写入数据的边界
协议层传输数据与DatagramPacket：
应用层与UDP之间 协议本质上传的是 一块字节数据+地址端口等元信息，JavaAPI把它们在应用层封装成了DatagramPacket对象 里面装着byte[]、address、port等成员
1.2应用层 <- 传输层
1.2.1TCP
TCP传输层把每个TCP报文****里面的应用层数据 堆放在无边界的字节流队列里 当前有连续有序的字节 就可向上流给应用层，应用层按量收取字节地处理
1.2.2UDP
UDP传输层把每个报文里面的应用层数据 每段地向上传 ，应用层选择合并或单独都可以地处理
2.传输层与网络层
2.1传输层 -> 网络层
传输层每个报文地传给网络层 都会分别地装进****每个IP包地 分开单独处理
2.1.1在网络层分片
如果一个传输层报文太大 超过某段链路层可承载的MTU 就会把所在的这个IP包拆成多个IP分片来发送
2.2传输层 <- 网络层
网络层每个IP包地向上传给传输层 出里面每个报文地 分开单独处理
2.2.1在网络层组片
目的主机的IP层 会把IP分片识别地重组回原个IP包 ，如果某个++IP分片丢失 就会放弃重组++此包
二、TCP的报头字段
1.序列号
1.1序列号seq
TCP报文头部的序列号 标识报文段数据部分第一个字节的编号，后面数据的字节默认依次+1得序
1.2初始序列号ISN
TCP建立连接第一次握手时 客户端<->服务器**++连接的每一发送方向++ 随机生成的起始seq序号，定位字节序号轴使用的起始位置 ，后续该连接里所有报文的seq、ack都在ISN基础上递增** 并以ISN为端轴表示出意义区间
1.3字节序号轴
一台主机向**++每个TCP连接的发送方向++ 都有每条独立的字节序号轴**，一条连接里面的每条消息 占在此连接的字节序号轴的不同区间内
1.3.1连接的四元组信息
通信的四元组已经确定了 哪两个主机里面的哪两个程序在通信
1.3.1.1四元组不同：互隔发送序号可以重叠
不同四元组的TCP连接 里面的消息的发送方向已经互隔 不会误达对方 ，它们TCP连接生成的ISN起始序号与每个报文使用的seq序列号 可以用同值 意义区间重叠
1.3.1.2四元组相同：一致发送序号可能互扰
同一四元组的先后TCP连接 里面的消息的发送方向相同，旧消息可能送往新连接 让外部不同连接环境里分配的旧序号 插排进来打扰排序
1.3.1.2.1措施
(1)窗口悬殊隔离
先后TCP连接生成的ISN起始序号 差值悬殊隔离很远 确保旧消息的报文序号不会落入新连接的可接收窗口 被误收
(2)关闭等待消失
先连接主动关闭的一方进入TIME.WAIT 不让同一四元组的消息复用 直到一段时间后网络里有的旧报文自然消失
1.4字节编号
TCP按稳定持久 的字节编号
1.4.1报文编号
1.4.1.1有序性
TCP按报文编号排序 能使得在传输层的报文有序 即外部排的报文有序，再加上报文内部排的字节有序 能使得传给应用层的数据字节有序
1.4.1.2不适点
1.4.1.2.1编序不稳定
应用层给TCP传输层传输字节流时 TCP可以变式切流装报文 ，应用数据与TCP报文段 编序不稳定
1.4.1.2.2存序不持久
TCP传输层给应用层传输字节流时 每个报文里面的数据字节放入字节流队列后 就没有了所在报文的边界 序号 也就此消失，应用数据与TCP报文段 存序不持久
2.确认序号
确认序号 = 接收到的最后一个字节的序号 + 1，根据确认序号：
- 对应字节序号轴区间 知道是哪个发去的报文 反馈的
- 知道此发去的报文 对方已经接收到了哪个字节
- 知道对方期望的 下一个收到的序号字节是哪个
3.校验和
3.1传输层使用Internet Checksum
按16位为单位 使用一补和地求和 溢出就回卷再加
3.2链路层使用CRC
漏检
校验不同报文的里面 可能会：
- ++有部分的结果小一点 而另部分的结果大一点++ 导致最终相加的和还是相同
- 不同结果的校验和 16bit空间不够 ++非线性轮回存++ 储地 存成相同了
4.数据偏移
TCP首部里的数据偏移字段 空间占4bit 数值在5~15 单位是4字节 ，表示TCP首部长度在20~60字节：
- 8个字段固定大小地共占20字节
- 选项字段按4字节填充补齐地变化
5.保留位
保留位是为将来的更新新增内容 在协议设计时已做 好了的 在空间上统一扩展的兼容
用光后
以后保留位用光后 做不到所有系统再能同时扩展保留位 导致TCP报文空间不同 收发无法兼容，因此：
- 用选项字段扩展
- 重新解释保留位
- 定义换用新协议
三、TCP的机制
网络上传输的错象
<1>路径丢包来得缺
丢包主要由网络路径上出问题造成的：
- 路由器队列满
- 链路误码
- 拥塞丢弃
- 分片丢失
- 设备故障
TCP和UDP一样概率地丢包，但TCP丢包后有恢复机制
1.超时重传->不怕丢
TCP发送端的发送缓冲区里的重传队列 会保留 还未确认对方接收的已发 送数据，出现：
- 数据段丢失 -> 接收端收不到数据
- ACK丢失 -> 接收端已收到数据
- 网络传输路上太堵 数据段到ACK 还没及时到达 -> 接收端会收到数据
就会导致发送端超过一定时间内没收到ACK确认 而重传
网络上传输的错象
<2>超时重传来得重
如果是接收端收了的数据重传 数据就会重复来了
1.1连续超时的指数退避
连续超时重传意味着：
- ++越小概率++ 是丢包
- ++越大概率++ 是网络拥塞/路径异常/故障
TCP会指数退避地拉长等待时间 降低发送频率来对应越小的丢包概率 以：
- ++减少++ 造成无效的重发 节省资源
- ++减缓++ 可能的网络拥塞
网络上传输的错象
<3>先发后至来得乱
网络上传输数据的速度可变不一致，先发 的网络数据包可能更后才到
2.排序去重->不怕重、不怕乱
TCP的每个连接都分配有一个接收缓冲区 ，会对发来的TCP报文的数据 按序号进行排序+去重地 缓存乱序段 与丢弃重复段
3.确认应答
TCP收到**++对方占有序号++** 的内容(数据、SYN、FIN) 会把接收效果的确认序号 放在ACK报文里 按相同四元组发回到同一个连接里
3.1捎带确认
ACK可以捎带正好要发的数据 给作报文里的载荷 一同发回，但是只是偶然去合并地 不负责作为此条消息的 是针对哪条消息回的标记
3.2针对回复
要针对哪条消息回复的标记 是选择写在应用层数据里完成的
4.TCP的三次握手
4.1握手意义
4.1.1建立连接(一套SYN+ACK一方建好)
明动机确知晓 地通建：
- SYN明自己有动机
- ACK确对方已知晓
=> 由此端通建
×2 => 两端都通建 就能打通 建立连接
建起连接时 也是已完成了的：
4.1.2协商信息(一套SYN+ACK一方发好)
SYN是 TCP协议专门为建立连接 定义的控制报文，在握手阶段里 ++消耗一个序号++ ++发送初始序号++ ++协商选项参数++
发SYN收ACK 能明确对方接收到 地 交换协商信息：
4.1.2.1初始序号
此端的初始序列号 明确对方接收到后 以后对方回复的ACK单值对应端轴出的接收区间 才有正确意义
4.1.2.2TCP选项
互相知道对方接收到了 发的SYN里面自端想要使用的信息地 协商TCP选项参数 谈好传输的规则：
- MSS，希望对方一次发给我的TCP数据 载荷最大多大
- Window Scale
- SACK许可
- Timestamp
- ECN
4.1.3检测通信(一套SYN+ACK一方测好)
收到ACK/SYN回复 能测出 通信端点的接发正常、通信道路的来去通顺
4.2握手技巧
4.2.1约定隐带
双方有共建的约定 通信时遵守 就能非存储数据形式地 额外隐式带上 ：
ACK消息双方都共建有 收到消息后再回 的约定，因此ACK消息里面还隐式带有 刚发消息对方已收到的约定信息
4.3握手流程
客户端new socket(serverIp, serverPort) 触发客户端内核开启三次握手
服务器new ServerSocket(port)触发服务器内核开启监听该端口 后 服务器内核参与三次握手
4.3.1.1客户端内核发送SYN[seq=x]
=>++SYN++ :客户端明自己有动机 、客户端向服务器发送协商信息
4.3.1.2服务器内核接收客户端内核发送的SYN
=>++SYN++ :服务器查看客户端的协商信息 、服务器测出 客户端发送能力+服务器接收能力正常and客户端->服务器的通信道路通顺
4.3.2.1服务器内核查看SYN的目的端口 是在监听中后 回复SYN+ACK[seq=y, ack=x+1]
=>++SYN++ :服务器明自己有动机 、服务器向客户端发送协商信息
->到服务器后查端口监听:说明消息是先到IP主机再查到端口程序的
->ack=x+1:握手时的ACK、SYN消息的TCP传输层 是没有应用层数据包载荷的单独报头，因此SYN的seq=x 收到ACK回复的期望值ack=x+1
4.3.2.2客户端内核接收服务器内核回复的SYN+ACK
=>++ACK++ :客户端确对方已知晓 向服务器通建连接 、客户端确定协商信息 服务器收到地发好 、客户端测出 客户端与服务器的发送接收能力正常and客户端<->服务器的通信道路通顺
=>++SYN++ :客户端查看服务器的协商信息 、客户端测出 服务器发送能力+客户端接收能力正常and客户端<-服务器的通信道路通顺
4.3.3.1客户端内核回复ACK[ack=y+1]
=>客户端内核创建 已与服务器建立连接的一个socket实体返回给应用层 才使用
4.3.3.2服务器内核接收客户端内核回复的ACK
=>++ACK++ :服务器确对方已知晓 向客户端通建连接 、服务器确定协商信息 客户端收到地发好 、服务器测出 客户端与服务器的发送接收能力正常and客户端<->服务器的通信道路通顺
=>服务器内核创建 会与多个客户端建立连接的一个socket实体 把连接放入socket的连接队列 里 由accept方法调用转执操作系统内核api 把内核里已经完成的连接取到应用层才使用