本文已参与「新人创作礼」活动，一起开启掘金创作之路。
传输层概念
位于网络层之上，提供主机之间的通信（端到端）。网络层协议不可靠，传输层可以提供可靠服务。
传输层复用：发送端不同的应用进程使用一个传输协议传送数据
传输层分用：接收方传输层在剥去报文首部可以正确交付应用程序
网络层复用：发送不同协议的数据都可以封装为IP数据报发送cq
网络层分用：接受方的网络层在去掉首部后交付给对应协议
传输层要对报文进行差错检测，网络层只检查首部（为什么要检测首部？因为首部出错可能发给人都不一样了，这个必须检查）
提供传输协议→ TCP & UDP （网络层要么只提供面向连接虚电路，要么只提供数据报）
熟知端口号：0-1023 登记端口号：1024-49151 临时端口号：49152-65535
采用TCP：FTP、HTTP、TELNET
采用UDP：TFTP、DNS、SNMP，RTP
TCP 首部20B，UDP首部8B
UDP
UDP支持单播，组播，广播
UDP 首部 → 源端口（2B），目的端口（2B），长度（2B），校验和（2B）
UDP 首部校验和是可选的
TCP
TCP是面向连接的协议
提供可靠交付（无差错、不丢失、不重复且有序）
全双工通信，双方设有缓存，以防止丢包重发
TCP面向字节流，一次交互一个数据块
UDP报文长度由发送应用进程来决定
TCP根据接收方给出的发送窗口值和当前网络拥塞程度来决定
数据偏移的单位是4B
URG 紧急位，尽快传送，高优先级，配合紧急指针使用
ACK确认位，建立连接后ACK置为1
PSH 推送位，尽快交付给应用程序，不等缓存满
RST 复位位，出现严重差错，必须释放连接
SYN同步位，表示这是一个连接请求或者接受报文
SYN = 1，ACK = 0，这是一个请求连接报文 响应 SYN=1，ACK=1
FIN 终止位，发送完毕，释放连接
窗口指对方允许发送的数据量
校验和计算与UDP一样，要加上12B的伪首部，把协议字段从17改为6
TCP 建立连接
SYN = 1，seq = x
SYN = 1，ACK = 1，seq = y，ack = x + 1
ACK = 1 , seq = x+1, ack = y + 1
第一次是server确认了client的发送能力
第二次是client确认了server的接受能力和发送能力
第三次是server确认了client的接受能力
TCP 释放连接
FIN = 1，seq = u
ack=1，seq=v，ack=u+1
FIN=1，ack=1，seq=w，ack=u+1
ACK=1，seq=u+1，ack=w+1
TCP发送报文
根据seq，当前序号指针和ack，下一个报文却来确认
接受窗口rwnd
拥塞窗口cwnd
拥塞控制的几种算法：慢开始、拥塞避免、快重传、快恢复
发送窗口的上限 = min（rwnd，cwnd）
ipv6
过滤ipv4手段：双协议栈，隧道技术
icmpv6 把icmp和igmp和arp融合掉了
多播路由选择协议方法
洪泛和剪除， 隧道技术，基于核心的发现技术
滑动窗口
接受方采用累加确认的方式来确定，不是逐步确认，收到几个分组后，对最后一个进行确认。
但是这个也有缺点，就是你是确认最后一个前面都到达的组的ack，所以就会导致可能出现回退N这种情况出现（12345，3丢失，45传到了也被迫重传）
如何解决这种问题？
使用选择确认 SACK，说明需要传输的块的偏移量
tcp 首部的选项
比如时间戳，比如窗口扩展，等选项，是可选的。
tcp的流量控制
流量控制是通过窗口值win来控制的
我发送了200kb数据，然后接收到的ack报文中显示win窗口变小了，比如只有100了。
那么我下次就只能发100的数据了，这个就相当于是流量控制，同步速率。
并且，我时不时的发送 ”窗口检测报文“， 以此来查询win窗口的大小，已决定自己发送的东西的多少。
tcp的拥塞控制
概念什么的，我不想背，其本质核心就是小心的试探，且使用最小的次数试探出拥塞窗口大小
慢开始：
首先把cwnd设置为swnd的一倍大，然后 1 2 4 8 . . . 这样翻倍增长。
等增长到 慢开始的门限ssthresh的时候，这个时候进入拥塞避免模式，逐步增加1
那么遇见超时了怎么处理呢？
重置ssthresh为当前cwnd的一半，也就是慢开始的门限，同时把cwnd重置为1。
为什么要这样子搞呢？很显然，倍增嘛，若下一次慢开始到了一个大于ssthresh的值。
再增加一次一定大于当前的上限了，我们这个时候应该选择拥塞避免算法来搞。
回想一下，是不是有点不太聪明啊，为什么我要重置为1？
重置为1是有理由的，网络拥塞了，确实需要重新试探。
但是，若是我只是丢包？被骗了。。。
那我还是要进入慢开始，慢慢试探
快重传
在接收方，我若是发送的是 12345，12ack恢复了，3的包丢失了，4的包发过来，我还是回复ack2，这样强迫发送方先发送3包，达到快重传的手段。
只要一连收到三次重复ack，ok，这个时候，该快重传了！
快恢复
重置ssthresh为当前cwnd的一半，那么，我是不是直接可以重拥塞避免算法开始搞。
