第11讲 | TCP协议(上):因性恶而复杂,先恶后善反轻松

2019-06-26  本文已影响0人  carlclone

知识点

1 TCP秉承性恶论 , 认为网络环境是复杂恶劣的

2 可能的情况: 丢包 , 乱序 , 重传 , 拥塞

3 UDP每个包只有端口号 , TCP包还多了序号 , 确认序号 , 都是32位

4 序号解决乱序问题

5 确认号解决丢包问题

6 best-effort 协议 尽最大努力保证可靠 , 极端情况网络差TCP也没办法

7 状态位 010101010….1010


image.png

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 结果


image.png

47 如何统计各连接状态的数量 https://www.jianshu.com/p/4dcef4b7ee06

image.png

48 awk的使用

49 之前学Socket的时候看到的建立连接的4元组数据结构 , 服务端什么时候保存客户端的IP和端口号

50 当时弄校园网认证路由器的时候接触过心跳包

上一篇 下一篇

猜你喜欢

热点阅读