01 | 网络模型和工具:网络为什么要分层?
该思维导图由 AI 生成,仅供参考
网络是七层、五层还是四层?
- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了网络分层模型的重要性和不同分层模型的特点,包括OSI的七层模型和TCP/IP的四层/五层模型。同时,还解释了TCP流的概念以及在网络报文层面的五元组和四元组的应用。文章还探讨了网络各层的排查工具,如应用层的HTTP应用排查工具和表示层、会话层的TLS排查工具。通过生动的比喻和清晰的解释,读者能够快速了解网络分层模型的重要性和不同模型的特点,以及TCP流的含义和应用。此外,还介绍了传输层的排查工具,包括路径可达性测试、查看当前连接状况、查看当前连接的传输速率以及丢包和乱序等的统计。这些工具能够帮助读者更好地了解传输层的状况,从而提高网络排查的效率。文章对于想要深入了解网络设计和排查技术的读者来说,具有启发性和实用价值。
《网络排查案例课》,新⼈⾸单¥59
全部留言(41)
- 最新
- 精选
- webmin1. traceroute 使用UDP探测时 初始时把TTL设置为1,经过路由器时TTL会被减1,当TTL变为0时,包被丢弃,路由器向源地址发回一个ICMP超时通知(ICMP Time Exceeded Message),源收到这个通知就会把下一次发送的包的TTL在原来的基础加1,这样就可以多前进一步,探测时使用了一个大于30000的端口号去连接,随着TTL的增加端口也会加1,目地服务器在收到这个数据包的时候会返回一个端口不可达的ICMP错误信息(ICMP Port Unreachable),当源地址收到ICMP Port Unreachable包时停止traceroute。 2. telnet挂起,连接请求还在服务端排队没有被accept(),进入到处理阶段,表现在Client就是挂起的现象。
作者回复: 1. 是的,TTL的操控是traceroute之类工具的核心,通过它实现了“逐跳”的探测。你这里提到了TTL为0时,路由器回复ICMP超时消息,这个补充非常好。 另外,文稿里的例子用默认UDP的方式遇到了“黑洞”,也就是对端并没有对这个UDP探测包回复IMCP port unreachable消息,但是它会对ICMP echo request探测包回复IMCP port unreachable消息,所以通过traceroute -I就可以看到完整的路径了。一般来说,对端要么对UDP模式有响应,要么对ICMP模式有响应,所以我们可以两个分别试一下。 2. 是的,telnet的握手SYN包发出去,但对端一直没回复SYN+ACK,导致telnet的connect()无法成功返回,造成了挂起。
2022-01-1258 - 罗辑思维telnet的握手SYN包发出去,但对端一直没回复SYN+ACK,导致telnet的connect()无法成功返回,造成了挂起。 这个一般会是什么原因呢? 是对端繁忙,还是防火墙呢?
作者回复: 嗯,这个要结合客户端和服务端的抓包,对比来分析: 1. 客户端抓包中有发出SYN,但在服务端抓包中没收到SYN,一般是客户端去往服务端的问题,检查这个方向上的网络设备;虚拟化情况下,也可能是客户端或者服务端VM/pod所在的hypervisor上的virtual switch等环节做了“手脚”,这些也在广义的网络设备范畴内,也要查; 2. 在服务端抓包中,发现SYN包进来了,但服务端没回SYN+ACK,那就检查本地是否有拦截(比如iptables)、端口监听是否正常、系统资源是否正常、应用的网络部分的代码是否正常、应用层的network syscall的返回是否正常; 3. 在服务端抓包中,发现SYN包进来了,自己也回了SYN+ACK,但客户端抓包中没收到SYN+ACK,推进方法跟1类似。 在1的服务端的入方向,tcpdump抓包发生在iptables规则起作用之前,所以如果SYN/SYN+ACK已经来了,tcpdump就能看到SYN,但iptables接着做拦截的话,这个连接也还是无法建立(跟网络上丢失的效果一致),这时候虽然见着了SYN但协议栈没回复SYN+ACK,却并不是协议栈的问题(而是iptables拦截导致)。这个分析也适用于3的客户端入方向。 可能没有涵盖所有情况,先想到这些:) 防火墙的话,会引起1和3,当然防火墙也会引起别的问题。关于防火墙的内容,下周上第5和第6课就可以学习到了。
2022-01-1413 - 追风筝的人应用层: http message 会话 表示层 TLS 传输层 TCP segment, UDP datagram 网络层: IP packet 数据链路层 ethnet frame 物理层 : 0 ,1 比特流
作者回复: 笔记挺好的:)
2022-02-1810 - Alex_Shen一. 原理 程序是利用增长存活时间(TTL)值来实现其功能的。每当数据包通过一个路由器,其存活时间就会减1。当其存活时间是0时,主机便取消数据包,并发送一个ICMP TTL数据包给原数据包的发出者。程序发出的首3个数据包TTL值是1,以后3个是2,如此类推,它便获得一连串数据包路径。注意IP不保证每一个数据包走的路径都同样。 1. Linux和Mac OS等系统使用UDP包进行探测,目标端口号默认为33434,每次探测目标端口号加1。Traceroute故意使用了一个大于 30000 的目标端口号,以保证目标地址收到数据包后能够返回一个“端口不可达”的 ICMP 报文,于是源地址就可将端口不可达报文当作跟踪结束的标志。 2.Traceroute每跳默认发送3个探测包(发包的数量可通过-q进行设置),探测包的返回会受到网络情况的影响。如果防火墙封掉了ICMP的返回信息,那么相应的延时位置会以*显示。如果某台网关阻塞或者某台DNS出现问题,那么相应行的延时会变长。可以加-n 参数来避免DNS解析,以IP格式输出数据。 3.每个探测包都有唯一的标识号,使得Traceroute能够识别返回的包。UDP数据包使用递增的目标端口号进行标识。 二. alex@alex-HVM-domU:~$ telnet www.baidu.com 443 Trying 180.101.49.11... Connected to www.a.shifen.com. Escape character is '^]'. ddddd Connection closed by foreign host. telnet百度是不是就是一个挂起的状态 不做任务操作就是一直是三次握手的状态,输入东西后就退出了 抓包后看不懂是不是没有正常的四次挥手退出,看到好像是两次挥手
作者回复: 回复100分:) 对于问题一,稍作补充:如果udp端口号不是递增,会有个问题是无法判断返回的time-to-live exceeded报文是代表了哪一跳。由于这个ttl exceeded报文携带了这次探测的udp端口号信息,比如是34440,减去base number33434,就是6,那么就是第6跳回复的。 问题二,抱歉可能大家对“挂起”的理解不完全一致,我原意是指telnet没有失败退出,也没有成功到提示符,而是处在尝试连接状态中。 telnet成功后,表示握手成功,这时,我们可以继续发送文本,比如GET / HTTP/1.1 Host: www.baidu.com 这就是一次模拟的HTTP请求。 可以参考我这边的实验结果: $ telnet www.baidu.com 80 Trying 180.101.49.11... Connected to www.a.shifen.com. Escape character is '^]'. GET / HTTP/1.1 Host: www.baidu.com HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: no-cache Connection: keep-alive Content-Length: 9508 Content-Type: text/html Date: Thu, 13 Jan 2022 13:19:58 GMT P3p: CP=" OTI DSP COR IVA OUR IND COM " P3p: CP=" OTI DSP COR IVA OUR IND COM "
2022-01-1337 - 柒小一TCP/IP Illusrated里强调了 TCP segment ,IP dategrame , frame来说明三层不同的叫法,这里有点糊涂了。
作者回复: 是的:) TCP的报文叫segment IP的报文叫datagram,其实UDP的也叫datagram 二层的叫frame segment是指“属于一个大块信息中的一部分”的报文,datagram是前后没有关系的相对独立的报文。 说到这里,你也可以联想一下VXLAN这个协议。作为overlay网络,为什么把UDP当做底层传输协议,而不是用TCP呢?我们可以对比一下普通网络和overlay网络: 普通网络(相对而言就是underlay网络):frame ( IP ( UDP/TCP ) ) overlay网络:outer frame ( outer IP ( outer UDP ( inner frame ( inner IP (inner UDP/TCP ) ) ) ) 一个建立在overlay网络上的传输层(也就是上面的inner UDP/TCP),本身已经完成了传输功能(比如TCP的话就是传输可靠性的保证等等特性),所以不需要在底层underlay网络再浪费资源做一次传输层保证了。而因为UDP跟IP都是datagram,不需要维护复杂的状态,所以被选为VXLAN的underlay协议。
2022-07-223 - 宝仔老师,加了-i之后,traceroute能跑完了,但是中间还有* 这个代表什么? traceroute to www.baidu.com (180.101.49.11), 30 hops max, 60 byte packets 1 10.4.16.74 (10.4.16.74) 2.567 ms 2.563 ms 2.561 ms 2 10.4.16.5 (10.4.16.5) 2.259 ms 2.535 ms 2.801 ms 3 11.168.161.18 (11.168.161.18) 2.108 ms 2.115 ms 2.115 ms 4 11.94.128.58 (11.94.128.58) 5.217 ms 5.196 ms 5.214 ms 5 10.102.41.85 (10.102.41.85) 4.932 ms 4.949 ms 5.020 ms 6 115.238.21.126 (115.238.21.126) 4.374 ms 6.067 ms 6.086 ms 7 220.191.200.209 (220.191.200.209) 8.263 ms 8.184 ms 8.224 ms 8 202.97.22.6 (202.97.22.6) 14.642 ms 14.650 ms * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 180.101.49.11 (180.101.49.11) 15.283 ms 15.292 ms 15.289 ms
作者回复: 恩蛮常见的现象,原因就是中间节点没有对icmp类型的消息做回复,但终点是做了。所以建议icmp和udp都做一遍,这样两张拼图互相缺失的部分就补起来了
2022-01-203 - webmin看到有同学问:“为什么udp port需要增加?” 我的理解是traceroute是探测,有可能会遇到有的路由器在TTL减为0时不做回应,traceroute在等超时以后还会努力去再去尝试探测下一跳,traceroute每次用的端口是Base Port + TLL,这样如果有回应包,traceroute就可以通过回应包中的目的地Port - BasePort就可以得知TTL是多少。 另这种机制也有利于traceroute可以并发发出多个UDP,每个包的TTL和端口不一样,只要根据回应包就可以得知TTL的信息。
作者回复: 很赞~ 是的,我观察到traceroute不是“挨个”探测的,而是一把发出多个不同TTL(和不同UDP端口)的探测报文,然后根据返回的情况,再判断的
2022-01-1323 - Dexter为什么udp port需要增加?没什么意义吧
作者回复: 看明白你的问题了,是指traceroute udp模式(也就是默认模式)下,为什么每次发送的udp探测包,其目的端口是递增的对吧?这样可以通过返回的ICMP消息里面携带的payload(这是一个“内嵌”的udp数据包),识别到这个ICMP是呼应了哪个udp探测包。如果每次端口号都相同,那所有的ICMP回复,就没有区别了,这并不是我们想要的。
2022-01-1233 - Geek_cad238关于TCP/IP五层模型和OSI的七层模型,最新版的CCNA官方教材有说明:https://note.youdao.com/s/F10GcERR
作者回复: 你的补充很好。确实,在业界用的多的还是OSI的模型
2022-01-2022 - 幕星max浏览器打开 F12, 有的网站 http header 那里, remote address 是 127.0.0.1:7890 这种本地地址, 这是为什么呢?我预期应该是公网地址才对啊
作者回复: 你应该是配置了本地代理吧,这个127.0.0.1:7890估计是你的代理服务器(就在本地)?
2022-01-1832