HTTP网络协议（三）
8～12课
TCP的几个要点
可靠传输
流量控制
拥塞控制
连接管理
-建立连接
-释放连接
TCP — 数据格式
数据偏移
-占四位，取值范围是0x0101~0x1111
-乘以4：首部长度（Head Length)
-首部长度是20～60字节
保留
-占6位，目前全为0
Q：为什么TCP长度那么长？
A：因为它可以做可靠传输、流量控制、拥塞控制
TCP - 小细节
有些资料中，TCP首部的保留（Reserved）字段占3位，标志（Flag）字段占9位
-Wireshark中也是如此
UDP首部有一个16位的字段记录了整个UDP报文段的长度（首部+数据）
但是，TCP的首部仅有个4位的字段记录了TCP报文段的首部长度，并没有字段记录TCP报文段的数据长度
分析
- UDP首部中占16位的长度字段是冗余的，存粹是为了保证首部是32bit对齐
- TCP（UDP）的数据长度，完全可以由IP数据包的首部推测出来，
传输层的数据长度= 网络层的总长度 - 网络层的首部长度 - 传输层的首部长度
UDP，通过网络层算出整体长度，再减去首部8位，就能算出数据长度
TCP，IP数据部分长度已知，数据偏移*4 = 首部长度，
TCP - 检验和（Checksum)
跟UDP一样，TCP检验和计算内容：伪首部 + 首部 + 数据
-伪首部：占用12个字节，仅在计算检验和时起作用，并不会传递给网络层
TCP - 标志位（Flags)
URG（Urgent）
当URG=1时，紧急指针字段才有效，表明当前报文段中有紧急数据，应优先尽快传送。
紧急指针，Flag URG = 1时，是紧急指针
ACK（Acknowledge）
当ACK=1时，确认号才有效
ack 标识号（小写）
PSH（Push)
RST（Reset)
当RST=1时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接
SYN（Synchronization）
当SYN=1、ACK为0时，表明这是一个建立连接的请求
若对方同意建立连接，则回复SYN=1、ACK=1
FIN（Finish）
当FIN=1时，表明数据已经发送完毕，要求释放连接
TCP - 序号、确认号、窗口
TCP
序号（Sequence Number）
-占四字节
-首先，在传输过程中的每一个字节都有一个编号
-在建立连接后，序号代表：这一次传给对方的TCP数据部分的第一个字节的编码
确认号（Acknowledgment Number)
-占四字节
-在建立连接后，确认号代表，期望对方下一次传过来的TCP数据部分的第一个字节的编号
窗口（Windows)
-占2字节
-这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）
流媒体是应用层的东西
可靠传输
-停止等待AQR协议
AQR协议（Automatic Repeat-reQuest), 自动重传请求
发送一个分组就停止发送等待确认
-连续ARQ协议 + 滑动窗口协议
TCP可靠传输 - SACK（选择性确认）
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: 占一字节，值为5代表这是SACK选项
-Length: 占一字节，表明SACK选项一共占用多少字节
-Left Edge: 占4字节，左边界
-Right Edge: 占4字节，右边界
09.TCP_02_流量控制_拥塞控制
Q：如果又个包重传了N次还是会失败，会一直持续重传到成功为止吗？
A：这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送reset报文（RST）断开TCP连接
UPD压根没有重传
Q：如果接收窗口最多能接收4个包，但对方只发送了两个包。接收方如何确定后面还有没有2个包
A：等待一定时间后，确认是否有第三个包
ACK 是传输层给传输层的回应（TCP）
思考一个问题
为什么选择在传输层就将数据“大卸八块”分为多个段，而不是等到网络层再分片传递给数据
-可以提高重传的性能
-需要明确的是，可靠传输实在传输层进行控制的
如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传
如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些数据即可
TCP-流量控制
如果接收方只能把收到的数据包丢掉，大量的丢包会极大浪费网络资源
所以要进行流量控制
什么是流量控制？
让发送方的发送速率不要太快，让接收方来得及接受处理
原理
通过确认报文中窗口字段来控制发送方的发送速率
发送方的发送窗口大小不能超过接收方给出窗口大小
当发送方姐收到窗口的大小为0时，发送方就会停止发送数据
wnd = windows
receive window = rwnd 接收窗口
有一种特殊情况
一开始，接收方给发送方发送了0窗口的报文段
后面，接收方又有了一些存储空间，发送方发送的非0窗口的报文段丢失了
发送方的发送窗口一直为0，双方陷入僵局
解决方案
-当发送方收到0窗口通知时，这时发送方停止发送报文
-并且同时开启一个定时器，隔一段时间就发一个测试报文去询问接收方最新的窗口大小
-如果接收到的窗口大小还是为0，则发送方再次刷新启动定时器
TCP-拥塞控制
-防止过多的数据注入到网络中
-避免网络中的路由器或链路过载
拥塞控制是一个全局性的过程
-涉及到所有主机、路由器
-以及与降低网络传输性能有关的所有因素
-是大家共同努力的结果
相比而言，流量控制是点对点通信的控制
TCP-拥塞控制 - 方法
慢开始（slow start 慢启动）
拥塞控制（congestion avoidance）
快速重传（fast retransmit)
快速恢复（fast recovery）
几个缩写
- MSS（Max Segment Size)：每个段最大的数据部分大小
-建立在连接时确定
-cwnd（congestion window) 拥塞窗口
-rwnd（receive window) 接收窗口
-swnd（send window) 发送窗口
-> swnd = min(cwnd, rwnd)
cwnd （congestion window) 拥塞窗口
rwnd （receive window）接收窗口
发送窗口= 拥塞窗口，当拥塞窗口超过接收窗口，发送窗口= 接收窗口
min(拥塞窗口，发送窗口）
拥塞控制-慢开始
刚开始发的慢，之后越来越快，呈指数型增长
cwnd的初始值比较小，然后随着数据包被接收方确认（收到一个ACK
cwnd就成倍增长（指数级）
拥塞控制-拥塞避免
ssthresh(slow start thresh）：慢开始阈值，cwnd达到阈值后，以线性方式增加
拥塞避免（加法增大）：拥塞窗口缓慢增大，以防止网络过早出现拥塞
乘法减小：只要出现网络拥塞，把ssthresh 减半，与此同时，执行慢开始算法（cwnd 又恢复到初始值
当网络出现频繁拥塞时，ssthresh值就下降得很快
拥塞控制-快重传
接收方
-每当收到一个失序的分组后就立即发送重复确认
-使发送方及时知道有分组没有到达
-而不要等待自己发送数据时才确认
发送方
-只要连续收到三个重复确认（总共四个相同的确认），就应当立即重传对方尚未收到的保温段
-而不必继续等待重传计时器到期后再重传
拥塞控制- 快重传 + 快恢复
当发送方连续收到三个重复确认，就执行”乘法减小”算法，把ssthresh减半
-与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值
-而是把cwnd值设置为ssthresh减半后的数值
-然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大
10.TCP03_序号确认号 建立连接
三次握手🤝
建立连接的过程
HTTP请求之前，要三次请求（建立连接）
SYN 标志位 序号seq(随机生成）
![PowerPoint ONT1802 - 107_14185.pptx] - PowerPoint.PNG](https://upload-images.jianshu.io/upload_images/1623463-34339e96b80701a2.PNG?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
《网络是怎么连接的》
第一次 SYN=1 ACK=0代表你想跟它建立连接 Len = 0（连接请求）
第二次 SYN=1 ACK=1 服务器有了回应 Len = 0,只有头部没有数据部分（连接请求确认）
第三次 SYN=0 ACK=1 Len = 0 （确认）
第四次正式发送HTTP请求，有数据，来自HTTP协议的数据部分
第五次 服务器返回数据，
发送方跟接收方是相对的，谁都能成为发送方
建立连接的数据部分长度为0，
Len = 0
ACK是对上一次发送方的回应
原生跟相对的关系，差了一个S1、S2
A客户端，B服务器
1.A->B：seq = s1, ack = 0
2.B->A：seq = s2, ack = s1 + 1
3.A->B：seq = s1 + 1, ack = s2 +1
4.A->B：seq = s1 + 1, ack = s2 + 1
5.B->A：seq = s2 + 1, ack=s1 + k + 1
6.B->A：seq = s2 + b1 + 1, ack=s1 + k + 1
7.B->A：seq = s2 + b1 + b2 + 1, ack=s1 + k + 1
8.B->A：seq = s2 + b1 + b2 + b3 + 1, ack=s1 + k + 1
TCP - 建立连接 - 3次握手
TCP - 建立连接 - 状态解读
CLOSED：client 处于关闭状态
LISTEN：server处于监听状态，等待client连接
SYN-RCVD：表示server接受了SYN保文，当收到client的ACK包问候，它会进入到ESTABLISHED状态（连接已经建立）
TCP - 建立连接 - 前两次握手的特点
-SYN都设置为1
-数据部分的长度是0
-TCP头部的长度是32字节
固定头部：20字节
选项部分：12字节
-双方会叫唤确认一些信息
比如MSS、是否支持SACK、Window scale （窗口缩放系数）等
这些数据都放在TCP头部的选择部分中（12字节）
TCP - 建立连接 - 疑问
Q：为什么是三次握手，不是两次握手
A：主要目的：防止server端一直在等待，浪费资源
A：如果两次，不能判断B能成功发送消息给A。
三次的话，可以保证A能发信息给B，B能收到A的信息，B能给A发信息，A能收到B的信息。保证了正常通信
A：如果两次，服务端发出确认，但client没有发出建立连接的请求，server以为新的运输连接已建立，并一直等待client发来数据，这样会造成资源浪费。
三次是保证双方互相明确对方能收发的最低值，其实就是双向握手+双向确认的过程
Q：加入建立连接只需要2次握手，可能会出现的情况
-假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放以后的某个时间才到达server
本来这是一个早已经失效的连接请求，但server收到实效的请求后，误以为是client再次发出一个新的连接请求
于是server就向client发送确认报文段，同意建立连接
如果不采用“三次握手”，那么只要server发出确认，新的连接就建立了
由于现在client并没有真正想连接服务器的意思，因此不会理睬server的确认，也不会向server发送数据
但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费了
->采用“三次握手”的办法可以防止上述现象发生
例如上述情况， client没有向server的确认发出确认，server由于收不到确认，就知道client并没有要求建立连接
Q：“第三次握手”失败了会怎么处理
此时server的状态为SYN-RCVD，若等不到client的ACK，server会重新发送SYN+ ACK包
如果server多次重发SYN+ACK都等不到client的ACK，就会发生RST包，强制关闭
11.TCP04_释放连接
四次挥手
Q：为什么释放连接的时候，要进行四次挥手
-TCP是全双工模式
-第一次挥手：当主机1发出FIN报文段时
表示主机1告诉主机2，主机1已经没有数据要发送了，但是，此时主机1还是可以接受来自主机2的数据
-第二次挥手：当主机2返回ACK 报文段时
表示主机2已经知道主机1没有数据发送了，但是主机2还是可以
-第三次挥手：当主机2页发送了FIN报文段时
表示主机2告诉主机1，主机2已经没有数据要发送了
-第四次挥手，当主机1返回ACK报文段时
表示主机1已经知道主机2没有数据发送了，随后正式断开整个TCP连接
状态解读
FIN-WAIT-1: 表示想主动关闭连接
-向对方发送了FIN报文，此时进入到FIN-WAIT-1状态
CLOSE-WAIT：表示等待关闭
-当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到CLOSE-WAIT状态
-在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方
FIN-WAIRT-2:只要对方发送ACK确认后，主动发就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文
CLOSEING：一种比较罕见的例外状态
-表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文
-如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态
LAST-ACK：被动关闭一方在发送FIN报文后，最后等待对方的ACK报文
-当收到ACK报文后，即可进入CLOUSED状态了
TIME-WAIT：表示收到了对方的FIN报文，并发送了ACK报文，就等2MSL后即可进入CLOSED状态了
-如果FIN-WAIT-1状态下，收到了对方同时带FIN标志和ACK标志的报文时
可以直接进入到TIME-WAIT状态，而无需经过FIN-WAIT-2状态
CLOSED：关闭状态
由于有些状态的时间比较短暂，所以很难用netstart命令看到，比如SYN-RCVD，FIN-WAIT-1等
TCP-释放连接-细节
-TCP/IP协议栈在设计上，允许任何一方先发起断开请求，这里演示的是client主动要求断开请求
Client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接
-一般是等待2倍的MSL（Maximum Segment Lifetime,最大分段生成期)
MSL是TCP报文在Internet上的最长生存时间
每个具体的TCP实现都必须选择一个确定的MSL值，RFC_1122建议是2分钟
可以防止本次连接中产生的数据包误传到下一次连接中（因为本次连接中的数据包都会在2MSL时间内失效）
-如果client发送ACK后马上释放了，然后又因为网络原因，server没有收到client的ACK，server就会重发FIN
这时可能出现的情况是
1.client没有任何回应，服务器那边会干等，甚至多次重发FIN，浪费资源
2.client有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来它可能是想跟server建立连接的
连接保活（应用层）
每隔一段时间发送数据包，每隔5s发送一个包
TCP-释放连接-抓包
-有时候在使用抓包工具的时候，有可能只会看到“3次”挥手
这其实是将第2、3次挥手合并了
-当server接收到client的FIN时，如果server后面也没有数据要发送给client了
这时，server就可以将第2、3次挥手合并，同时告诉client两件事
1.已经知道client没有数据要发
2.server已经没有数据要发了
12.Socket 补充_域名
Q：我们常常提到的长连接和短连接是如何区分的
A：看交互方式，交互之后就关闭，是短连接。交互频繁，使用长连接。
长连接释放时间由开发决定。
Q：建设建立连接之后，没有断开
A： 不断开连接，对网卡无影响，网卡是用来收发数据的。
不断开连接，对方的socket对象保存在内存里，对内存有影响。
网卡的带宽越高，传输速度就越快。
Q：假设数据数据太多，网卡已经接受不过来数据，直接丢弃。
那这个时候的数据是不是只穿到了物理层，但是上不到数据链路层
A：已经到了链路层，但是缓冲区不够，进不了缓冲区就扔掉了
