知识点
1 TCP秉承性恶论 , 认为网络环境是复杂恶劣的
2 可能的情况: 丢包 , 乱序 , 重传 , 拥塞
3 UDP每个包只有端口号 , TCP包还多了序号 , 确认序号 , 都是32位
4 序号解决乱序问题
5 确认号解决丢包问题
6 best-effort 协议 尽最大努力保证可靠 , 极端情况网络差TCP也没办法
7 状态位 010101010….1010
8 SYN发起连接
9 ACK回复
10 RST重新连接
11 FIN结束连接
12 窗口大小 16位 , 标识自己能够处理的数据量
13 拥塞控制 , 尽力缓解网络堵车问题
14 三次握手 , 为什么是3次 , 不是两次 , 假设法 , 网络环境非常差
15 请求-> 应答 -> 应答的应答
16 A发了好多次请求 , B终于收到了 , B应答 , 但是B不能确定A收到应答了 , 所以不能认为连接建立
17 一个诡异的握手案例
18 保证消息都有去有回就基本可以了
19 大部分情况建立连接后都会立即发送数据 , B就可以知道连接建立正常了
20 如果A建立连接后一直不发数据 , 可以用keepalive机制 , 俗称心跳包 , 也可以关闭节省资源
21 三次握手双方还会交换初始序号 , 不是从1开始的 , 因为容易冲突
22 冲突案例: A发送1,2,3包, 包3丢了重传 , 但是A掉线重连了 , 然后发数据又从1,2开始 , 发送1,2包的时候, 上一个连接的包3突然到了, 产生了错误
23 初始序号按时间生成 , 32位计数器 , 每4ms+1 , 远大于TTL时间
24 TTL 生存时间 , 超出则丢弃
25 TCP握手时序状态机图 , 自己画一遍?
26 四次握手的半关闭状态 , 被动关闭一方还没发完数据 , 此时还可以发
27 几种单方面异常直接跑路情况
28 A说完不玩了直接跑 , 会发生什么
29 A说完不玩了 , B直接跑 , 会发生什么
30 TCP为了解决上面问题设计的断开连接状态
31 断开连接的时序状态机图 , 自己画一遍
32 列出4次握手的状态 : FIN_WAIT_1 CLOSED_WAIT FIND_WAIT_2 TIME_WAIT LAST_ACK CLOSED
33 状态之间转换的过程?
34 tcp_fin_timeout 解决B直接跑后 , A还在等的问题
35 TIME_WAIT解决什么问题
36 A直接跑路引发的另一个问题 : 端口空出来 , 被新的应用使用了 , 虽然有初始序列号 , 但为了双保险还是要TIME_WAIT , 等包都死完了再断开空出端口
37 MSL = Maximum Segment Lifetime , 报文最大生存时间 , 这个是时间 , TTL是跳
38 ICMP作用是?
39 MSL一般是2分钟 , 实际可以用30s , 1min , 2min
40 TIME_WAIT等待2MSL
41 另一个极端情况 , B超过了2MSL还没收到ACK , A直接发RST , 那RST也丢了呢? A不管那么多啦 ,仁至义尽
42 一张TCP状态机的图 , 要结合时序状态机图看才不会晕菜
43 思考题两个 1 如何在系统中查看某个连接的状态 2 这节讲的只是维护连接的状态 , 还有其他数据结构处理其他问题, 有哪些?
44 使用netstat 查看连接
45 查看8080端口 TIME_WAIT的连接 netstat -tan | grep 8080 | grep TIME_WAIT | wc -l
46 wc是什么命令 , word count ,
man wc 结果
47 如何统计各连接状态的数量 https://www.jianshu.com/p/4dcef4b7ee06
48 awk的使用
49 之前学Socket的时候看到的建立连接的4元组数据结构 , 服务端什么时候保存客户端的IP和端口号
50 当时弄校园网认证路由器的时候接触过心跳包
