计算机网络基础之TCP/IP 协议栈
计算机网络基础之TCP/IP 协议栈
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
一.TCP/IP 协议栈概述
1>.什么是TCP/IP协议栈
Transmission Control Protocol/Internet Protocol 传输控制协议/因特网互联协议 TCP/IP是一个Protocol Stack，包括TCP、IP、UDP、ICMP、RIP、TELNET、FTP、SMTP、ARP等许多协议 最早发源于美国国防部（缩写为DoD）的因特网的前身ARPA网项目，1983年1月1日，TCP/IP取代了旧的网络控制协议NCP，成为今天的互联网和局域网的基石和标准,由互联网工程任务组负责维护 共定义了四层，分别为网络访问层，Internet层，传输层，应用层。 和ISO参考模型的分层有对应关系如下图所示。
2>.TCP/IP 应用层
3>.传输层
4>.可靠性 vs.高效性
5>.TCP特性
工作在传输层
面向连接协议
全双工协议
半关闭
错误检查
将数据打包成段，排序
确认机制
数据恢复，重传
流量控制，滑动窗口
拥塞控制，慢启动和拥塞避免算法
二.TCP协议
1>.TCP包头信息
源端口(source port)、目标端口(dest port)： 计算机上的进程要和其他进程通信是要通过计算机端口的，而一个计算机端口某个时刻只能被一个进程占用，所以通过指定源端口和目标端口，就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的，可推算计算机的端口个数为2^16个 序列号(sequence)： 表示本报文段所发送数据的第一个字节的编号。在TCP连接中所传送的字节流的每一个字节都会按顺序编号。由于序列号由32位表示，所以每2^32个比特位，就会出现序列号回绕，再次从 0 开始 确认号(acknowledgment)： 表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。也就是告诉发送方：我希望你（指发送方）下次发送的数据的第一个字节数据的编号为此确认号 数据偏移： 表示TCP报文段的首部长度，共4位，由于TCP首部包含一个长度可变的选项部分，需要指定这个TCP报文段到底有多长。它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。该字段的单位是32位(即4个字节为计算单位），4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节 URG： 表示本报文段中发送的数据是否包含紧急数据。后面的紧急指针字段（urgent pointer）只有当URG=1时才有效 ACK： 表示是否前面确认号字段是否有效。只有当ACK=1时，前面的确认号字段才有效。TCP规定，连接建立后，ACK必须为1,带ACK标志的TCP报文段称为确认报文段 PSH： 提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间。如果为1，则表示对方应当立即把数据提交给上层应用，而不是缓存起来，如果应用程序不将接收到的数据读走，就会一直停留在TCP接收缓冲区中 RST： 如果收到一个RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。或者说明上次发送给主机的数据有问题，主机拒绝响应，带RST标志的TCP报文段称为复位报文段 SYN： 在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接。SYN=1，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段 FIN： 表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果FIN=1，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段 窗口大小： 表示现在允许对方发送的数据量，也就是告诉对方，从本报文段的确认号开始允许对方发送的数据量，达到此值，需要ACK确认后才能再继续传送后面数据，由Window size value * Window size scaling factor（此值在三次握手阶段TCP选项Window scale协商得到）得出此值 校验和： 提供额外的可靠性 紧急指针： 标记紧急数据在数据字段中的位置 选项部分： 其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，选项部分最长为：(2^4-1)*4-20=40字节 常见选项： 最大报文段长度：Maxium Segment Size，MSS，通常1460字节 窗口扩大：Window Scale 时间戳： Timestamps
2>.TCP包头选项
最大报文段长度MSS（Maximum Segment Size） 指明自己期望对方发送TCP报文段时那个数据字段的长度。比如：1460字节。数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS不宜设的太大也不宜设的太小。若选择太小，极端情况下，TCP报文段只含有1字节数据，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，网络的利用率就不会超过1/41。若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传，这些也都会使开销增大。因此MSS应尽可能大，只要在IP层传输时不需要再分片就行。在连接建立过程中，双方都把自己能够支持的MSS写入这一字段。 MSS只出现在SYN报文中。即：MSS出现在SYN=1的报文段中 MTU和MSS值的关系：MTU=MSS+IP Header+TCP Header 通信双方最终的MSS值=较小MTU-IP Header-TCP Header 窗口扩大 为了扩大窗口，由于TCP首部的窗口大小字段长度是16位，所以其表示的最大数是65535。但是随着时延和带宽比较大的通信产生（如卫星通信），需要更大的窗口来满足性能和吞吐率，所以产生了这个窗口扩大选项 时间戳 可以用来计算RTT(往返时间)，发送方发送TCP报文时，把当前的时间值放入时间戳字段，接收方收到后发送确认报文时，把这个时间戳字段的值复制到确认报文中，当发送方收到确认报文后即可计算出RTT。也可以用来防止回绕序号PAWS，也可以说可以用来区分相同序列号的不同报文。因为序列号用32为表示，每2^32个序列号就会产生回绕，那么使用时间戳字段就很容易区分相同序列号的不同报文
3>.映射第四层到应用程序
常见的应用层服务被分配的默认端口: FTP:21(TCP) TELNET:23(TCP) HTTTP:80(TCP) DNS:53(TCP,UDP) TFTP:69(UDP) SNMP:161(UDP)
4>.TCP协议PORT
传输层通过port号，确定应用层协议 Port number: tcp：传输控制协议，面向连接的协议；通信前需要建立虚拟链路；结束后拆除链路 0-65535 udp：User Datagram Protocol，无连接的协议 0-65535 IANA:互联网数字分配机构（负责域名，数字资源，协议分配） 0-1023：系统端口或特权端口(仅管理员可用) ，众所周知，永久的分配给固定的系统应用使用，22/tcp(ssh), 80/tcp(http), 443/tcp(https) 1024-49151：用户端口或注册端口，但要求并不严格，分配给程序注册为某应用使用，1433/tcp(SqlServer), 1521/tcp(oracle),3306/tcp(mysql),11211/tcp/udp (memcached) 49152-65535：动态端口或私有端口，客户端程序随机使用的端口 其范围的定义：/proc/sys/net/ipv4/ip_local_port_range
[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/ip_local_port_range 32768 60999 [root@node101.yinzhengjie.org.cn ~]#
5>.TCP三次握手
client端首先发送一个SYN包(在建立连接时使用，用来同步序号)告诉server端我的初始序列号是X client端收到SYN包后回复给Client一个ACK确认包，告诉Client说我收到了。Server端也需要告诉Client端自己的初始序列号，于是server也发送一个SYN包告诉Client端我的序列化时y。这两个包一起发送。 client收到后，回复server一个ACK确认包说我知道了。 温馨提示:(Linux抓取现有连接状态及排序) [root@node101.yinzhengjie.org.cn ~]# ss -nt | sed -rn '1!s/^([^ ]+).*/\1/p' | sort | uniq -c
6>.TCP四次挥手
client发送一个FIN包来告诉server需要断开
server端收到后回复一个ACK确认FIN包收到
server在自己也没有数据发送给client后，server也发送一个FIN包给client，表示也无数据发送了
client收到后，就会回复一个ACK确认server的FIN包
温馨提示:
不是只有客户端才能发送断开请求，主动发出Fin包就是主动关闭方，就会进入TIME_WAIT，原因时被动关闭方发来的FIN包需要确认，万一此包丢失，被动关闭方未收到确认会超时重发FIN包，主动关闭方还在，可以重发ACK。
7>.有限状态机FSM:Finite State Machine
CLOSED 没有任何连接状态 LISTEN 侦听状态，等待来自远方TCP端口的连接请求 SYN-SENT 在发送连接请求后，等待对方确认 SYN-RECEIVED 在收到和发送一个连接请求后，等待对方确认 ESTABLISHED 代表传输连接建立，双方进入数据传送状态 FIN-WAIT-1 主动关闭,主机已发送关闭连接请求，等待对方确认 FIN-WAIT-2 主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭传输连接请求 TIME-WAIT 完成双向传输连接关闭，等待所有分组消失 CLOSE-WAIT 被动关闭,收到对方发来的关闭连接请求，并已确认 LAST-ACK 被动关闭,等待最后一个关闭传输连接确认，并等待所有分组消失 CLOSING 双方同时尝试关闭传输连接，等待对方确认 客户端先发送一个FIN给服务端，自己进入了FIN_WAIT_1状态，这时等待接收服务端的报文，该报文会有三种可能： (1)只有服务端的ACK 只收到服务器的ACK，客户端会进入FIN_WAIT_2状态，后续当收到服务端的FIN时，回应发送一个ACK，会进入到TIME_WAIT状态，这个状态会持续2MSL(TCP报文段在网络中的最大生存时间, RFC 1122标准的建议值是2min).客户端等待2MSL，是为了当最后一个ACK丢失时，可以再发送一次。因为服务端在等待超时后会再发送一个FIN给客户端，进而客户端知道ACK已丢失 (2)只有服务端的FIN 只有服务端的FIN时，回应一个ACK给服务端，进入CLOSING状态，然后接收到服务端的ACK时，进入TIME_WAIT状态 (3)基于服务端的ACK，又有FIN 同时收到服务端的ACK和FIN，直接进入TIME_WAIT状态
8>.客户端的典型状态转移
客户端通过connect系统调用主动与服务器建立连接connect系统调用首先给服务器发送一个同步报文段，使连接转移到SYN_SENT状态 此后connect系统调用可能因为如下两个原因失败返回： 1、如果connect连接的目标端口不存在（未被任何进程监听），或者该端口仍被处于TIME_WAIT状态的连接所占用（见后文），则服务器将给客户端发送一个复位报文段，connect调用失败。 2、如果目标端口存在，但connect在超时时间内未收到服务器的确认报文段，则connect调用失败。 connect调用失败将使连接立即返回到初始的CLOSED状态。如果客户端成功收到服务器的同步报文段和确认，则connect调用成功返回，连接转移至ESTABLISHED状态 当客户端执行主动关闭时，它将向服务器发送一个结束报文段，同时连接进入FIN_WAIT_1状态。若此时客户端收到服务器专门用于确认目的的确认报文段，则连接转移至FIN_WAIT_2状态。当客户端处于FIN_WAIT_2状态时，服务器处于CLOSE_WAIT状态，这一对状态是可能发生半关闭的状态。此时如果服务器也关闭连接（发送结束报文段），则客户端将给予确认并进入TIME_WAIT状态 客户端从FIN_WAIT_1状态可能直接进入TIME_WAIT状态（不经过FIN_WAIT_2状态），前提是处于FIN_WAIT_1状态的服务器直接收到带确认信息的结束报文段（而不是先收到确认报文段，再收到结束报文段） 处于FIN_WAIT_2状态的客户端需要等待服务器发送结束报文段，才能转移至TIME_WAIT状态，否则它将一直停留在这个状态。如果不是为了在半关闭状态下继续接收数据，连接长时间地停留在FIN_WAIT_2状态并无益处。连接停留在FIN_WAIT_2状态的情况可能发生在：客户端执行半关闭后，未等服务器关闭连接就强行退出了。此时客户端连接由内核来接管，可称之为孤儿连接（和孤儿进程类似） Linux为了防止孤儿连接长时间存留在内核中，定义了两个内核参数： /proc/sys/net/ipv4/tcp_max_orphans 指定内核能接管的孤儿连接数目 /proc/sys/net/ipv4/tcp_fin_timeout 指定孤儿连接在内核中生存的时间
[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_max_orphans 32768 [root@node101.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout 60 [root@node101.yinzhengjie.org.cn ~]#
9>.TCP协议中的三次握手和四次挥手
10>.客户机端的三次握手和四次挥手
11>.服务器端的三次握手和四次挥手
12>.sync半连接和accept全连接队列
ss –lnt /proc/sys/net/ipv4/tcp_max_syn_backlog #未完成连接(sync半连接)队列大小，建议调整大小为1024以上 /proc/sys/net/core/somaxconn #完成连接(accept全连接)队列大小，建议调整大小为1024以上
[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_max_syn_backlog 256 [root@node101.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/core/somaxconn 128 [root@node101.yinzhengjie.org.cn ~]#
13>.TCP超时重传
异常网络状况下（开始出现超时或丢包），TCP控制数据传输以保证其承诺的可靠服务 TCP服务必须能够重传超时时间内未收到确认的TCP报文段。为此，TCP模块为每个TCP报文段都维护一个重传定时器，该定时器在TCP报文段第一次被发送时启动。如果超时时间内未收到接收方的应答，TCP模块将重传TCP报文段并重置定时器。至于下次重传的超时时间如何选择，以及最多执行多少次重传，就是TCP的重传策略 与TCP超时重传相关的两个内核参数： /proc/sys/net/ipv4/tcp_retries1，指定在底层IP接管之前TCP最少执行的重传次数，默认值是3 /proc/sys/net/ipv4/tcp_retries2，指定连接放弃前TCP最多可以执行的重传次数，默认值15（一般对应13～30min）
[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_retries1 3 [root@node101.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_retries2 15 [root@node101.yinzhengjie.org.cn ~]#
14>.TCP确认
15>.固定窗口
16>.TCP滑动窗口
17>.拥塞控制
网络中的带宽、交换结点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可承受的能力，网络的性能就会变坏。此情况称为拥塞 TCP为提高网络利用率，降低丢包率，并保证网络资源对每条数据流的公平性。即所谓的拥塞控制 TCP拥塞控制的标准文档是RFC 5681，其中详细介绍了拥塞控制的四个部分：慢启动（slow start）、拥塞避免（congestion avoidance）、快速重传（fast retransmit）和快速恢复（fast recovery）。拥塞控制算法在Linux下有多种实现，比如reno算法、vegas算法和cubic算法等。它们或者部分或者全部实现了上述四个部分 当前所使用的拥塞控制算法 /proc/sys/net/ipv4/tcp_congestion_control
[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_congestion_control cubic [root@node101.yinzhengjie.org.cn ~]#
三.UDP协议
1>.UDP特性
工作在传输层
提供不可靠的网络访问
非面向连接协议
有限的错误检查
传输性能高
无数据恢复特性
2>.UDP包头
UDP报文头部的确很简单，如下图所示。
UDP没有三次握手的繁琐操作，发送数据那是相当的快啊，在网络比较稳定的情况下可以采用UDP协议，比如内网传输数据，其中DNS协议不仅仅是可以使用TCP的53端口，还使用了UDP的53端口。
四.Internet层
1>.Internet Control Message Protocol(简称"ICMP")
它是基于internet层之上一种协议，但并不是传输层协议，因为它压根就没有传输的功能。 ICMP（Internet Control Message Protocol）Internet控制报文协议。它是TCP/IP协议簇的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。 通过抓包工具可以发现当ICMP包的类型为"8"则表示request请求报文，如果类型为"0"则表示reply回应报文。因此我们可以根据这个特点在服务器端配置相应的策略来实现禁ping的效果。 在Linux系统中，除了上面所说的根据ICMP报文类型编写相应的防火墙策略来实现禁ping的效果，其实也可以直接关闭一个内核参数就可以轻松实现禁ping: [root@node101.yinzhengjie.org.cn ~]# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
[root@node102.yinzhengjie.org.cn ~]# ping -c 10 172.30.1.101 #指定ping的次数为10次 PING 172.30.1.101 (172.30.1.101) 56(84) bytes of data. 64 bytes from 172.30.1.101: icmp_seq=1 ttl=64 time=0.344 ms 64 bytes from 172.30.1.101: icmp_seq=2 ttl=64 time=0.531 ms 64 bytes from 172.30.1.101: icmp_seq=3 ttl=64 time=0.316 ms 64 bytes from 172.30.1.101: icmp_seq=4 ttl=64 time=0.302 ms 64 bytes from 172.30.1.101: icmp_seq=5 ttl=64 time=0.374 ms 64 bytes from 172.30.1.101: icmp_seq=6 ttl=64 time=0.287 ms 64 bytes from 172.30.1.101: icmp_seq=7 ttl=64 time=0.790 ms 64 bytes from 172.30.1.101: icmp_seq=8 ttl=64 time=0.314 ms 64 bytes from 172.30.1.101: icmp_seq=9 ttl=64 time=0.624 ms 64 bytes from 172.30.1.101: icmp_seq=10 ttl=64 time=0.799 ms --- 172.30.1.101 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9009ms rtt min/avg/max/mdev = 0.287/0.468/0.799/0.193 ms [root@node102.yinzhengjie.org.cn ~]#
[root@node102.yinzhengjie.org.cn ~]# ping -c 10 -w 1 172.30.1.101 #无论是否ping通，只ping一次 PING 172.30.1.101 (172.30.1.101) 56(84) bytes of data. 64 bytes from 172.30.1.101: icmp_seq=1 ttl=64 time=0.367 ms --- 172.30.1.101 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.367/0.367/0.367/0.000 ms [root@node102.yinzhengjie.org.cn ~]# [root@node102.yinzhengjie.org.cn ~]# [root@node102.yinzhengjie.org.cn ~]# ping -w 1 172.30.1.101 PING 172.30.1.101 (172.30.1.101) 56(84) bytes of data. 64 bytes from 172.30.1.101: icmp_seq=1 ttl=64 time=0.386 ms --- 172.30.1.101 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.386/0.386/0.386/0.000 ms [root@node102.yinzhengjie.org.cn ~]# [root@node102.yinzhengjie.org.cn ~]#
[root@node102.yinzhengjie.org.cn ~]# ping -s 5000 172.30.1.101 -c 1 #指定ICMP数据为5000字节 PING 172.30.1.101 (172.30.1.101) 5000(5028) bytes of data. 5008 bytes from 172.30.1.101: icmp_seq=1 ttl=64 time=0.253 ms --- 172.30.1.101 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.253/0.253/0.253/0.000 ms [root@node102.yinzhengjie.org.cn ~]# [root@node102.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]# tcpdump -i enp0s8 icmp #使用tcpdump之抓取ICMP协议的包。从结果上看虽然ping了一次，但是由于一个包最大能传输1500个字节，因此5000个字节被拆除了4个包进行request和reply tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes 00:57:40.069101 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18137, seq 1, length 1480 00:57:40.069116 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: icmp 00:57:40.069118 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: icmp 00:57:40.069120 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: icmp 00:57:40.069135 IP node101.yinzhengjie.org.cn > node102.yinzhengjie.org.cn: ICMP echo reply, id 18137, seq 1, length 1480 00:57:40.069149 IP node101.yinzhengjie.org.cn > node102.yinzhengjie.org.cn: icmp 00:57:40.069156 IP node101.yinzhengjie.org.cn > node102.yinzhengjie.org.cn: icmp 00:57:40.069163 IP node101.yinzhengjie.org.cn > node102.yinzhengjie.org.cn: icmp
[root@node102.yinzhengjie.org.cn ~]# ping -s 65507 192.168.124.14 -f #其实我们也可以使用ping发起flood ping攻击。可以ping一下自己的网卡地址，打开操作系统的任务管理器，观察网卡的使用情况。 PING 192.168.124.14 (192.168.124.14) 65507(65535) bytes of data. ................................................................................................................................................. ...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................^X.^@...........................................^C--- 192.168.124.14 ping statistics --- 3644 packets transmitted, 0 received, 100% packet loss, time 42199ms [root@node102.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/icmp_echo_ignore_all 0 [root@node101.yinzhengjie.org.cn ~]# [root@node101.yinzhengjie.org.cn ~]# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all #禁ping [root@node101.yinzhengjie.org.cn ~]# [root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/icmp_echo_ignore_all 1 [root@node101.yinzhengjie.org.cn ~]# [root@node101.yinzhengjie.org.cn ~]#
[root@node102.yinzhengjie.org.cn ~]# ping -c 10 172.30.1.101 #由于上面已经警ping了，可以ping10次 PING 172.30.1.101 (172.30.1.101) 56(84) bytes of data. --- 172.30.1.101 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9004ms [root@node102.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]# tcpdump -i enp0s8 icmp #我们发现只接收到了request请求，但由于我们禁ping啦，导致没有回应报文。 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes 01:14:29.524064 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18245, seq 1, length 64 01:14:30.523441 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18245, seq 2, length 64 01:14:31.524017 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18245, seq 3, length 64 01:14:32.524016 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18245, seq 4, length 64 01:14:33.524429 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18245, seq 5, length 64 01:14:34.525335 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18245, seq 6, length 64 01:14:35.525509 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18245, seq 7, length 64 01:14:36.526486 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18245, seq 8, length 64 01:14:37.527528 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18245, seq 9, length 64 01:14:38.528448 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id 18245, seq 10, length 64
2>.Address Resolution Protocol(简称"ARP")
地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机，并接收返回消息，以此确定目标的物理地址；收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。
细心的小伙伴可能也发现了，还有一种特殊的Gratuitous ARP，它是在机器开始的时候发出一种ARP，其目的在于询问局域网中是否有对应的主机使用了当前主机所分配的IP地址，从而避免地址冲突。可以用虚拟机模拟此常见(需要用相应的抓包工具)
C:\Users\yinzhengjie>arp -a #Windows查看ARP列表 接口: 192.168.30.1 --- 0x2 Internet 地址 物理地址 类型 192.168.30.254 00-50-56-fa-b2-5b 动态 192.168.30.255 ff-ff-ff-ff-ff-ff 静态 224.0.0.2 01-00-5e-00-00-02 静态 224.0.0.22 01-00-5e-00-00-16 静态 224.0.0.251 01-00-5e-00-00-fb 静态 224.0.0.252 01-00-5e-00-00-fc 静态 239.255.255.250 01-00-5e-7f-ff-fa 静态 255.255.255.255 ff-ff-ff-ff-ff-ff 静态 接口: 172.30.1.254 --- 0xf Internet 地址 物理地址 类型 172.30.1.101 08-00-27-c1-c7-46 动态 172.30.1.102 08-00-27-1d-d2-80 动态 172.30.1.255 ff-ff-ff-ff-ff-ff 静态 224.0.0.2 01-00-5e-00-00-02 静态 224.0.0.22 01-00-5e-00-00-16 静态 224.0.0.251 01-00-5e-00-00-fb 静态 224.0.0.252 01-00-5e-00-00-fc 静态 239.255.255.250 01-00-5e-7f-ff-fa 静态 接口: 172.30.1.1 --- 0x10 Internet 地址 物理地址 类型 172.30.1.255 ff-ff-ff-ff-ff-ff 静态 224.0.0.2 01-00-5e-00-00-02 静态 224.0.0.22 01-00-5e-00-00-16 静态 224.0.0.251 01-00-5e-00-00-fb 静态 224.0.0.252 01-00-5e-00-00-fc 静态 239.255.255.250 01-00-5e-7f-ff-fa 静态 接口: 192.168.124.14 --- 0x15 Internet 地址 物理地址 类型 192.168.124.1 04-40-a9-ce-c6-92 动态 192.168.124.255 ff-ff-ff-ff-ff-ff 静态 224.0.0.2 01-00-5e-00-00-02 静态 224.0.0.22 01-00-5e-00-00-16 静态 224.0.0.251 01-00-5e-00-00-fb 静态 224.0.0.252 01-00-5e-00-00-fc 静态 239.255.255.250 01-00-5e-7f-ff-fa 静态 255.255.255.255 ff-ff-ff-ff-ff-ff 静态 C:\Users\yinzhengjie> C:\Users\yinzhengjie>
[root@node101.yinzhengjie.org.cn ~]# arp -n #Linux查看ARP列表 Address HWtype HWaddress Flags Mask Iface 172.30.1.254 ether 0a:00:27:00:00:0f C enp0s8 10.0.2.2 ether 52:54:00:12:35:02 C enp0s3 172.30.1.102 ether 08:00:27:1d:d2:80 C enp0s8 [root@node101.yinzhengjie.org.cn ~]# [root@node101.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]# ip neigh #Linux查看ARP列表方式二 172.30.1.254 dev enp0s8 lladdr 0a:00:27:00:00:0f DELAY 10.0.2.2 dev enp0s3 lladdr 52:54:00:12:35:02 STALE 172.30.1.102 dev enp0s8 lladdr 08:00:27:1d:d2:80 STALE [root@node101.yinzhengjie.org.cn ~]#
3>.反向ARP
反向ARP是根据源设备MAC地址通过广播获取IP地址的过程的地址解析协议。
4>.Internet 协议特征
运行于 OSI 网络层
面向无连接的协议
独立处理数据包
分层编址
尽力而为传输
无数据恢复功能
5>.IP PDU 报头
IP报文头部信息如下图所示:
版本:
占4位,指 IP 协议的版本目前的IP协议版本号为4 首部长度:
占4位,可表示的最大数值是15个单位，一个单位为4字节，因此IP 的首部长度的最大值是60字节 区分服务:
占8位,用来获得更好的服务,在旧标准中叫做服务类型,但实际上一直未被使用过.后改名为区分服务.只有在使用区分服务(DiffServ)时,这个字段才起作用.一般的情况下不使用 总长度:
占16位,指首部和数据之和的长度,单位为字节,因此数据报的最大长度为 65535 字节.总长度必须不超过最大传送单元 MTU 标识:
占16位,它是一个计数器,通常，每发送一个报文，该值会加1， 也用于数据包分片，在同一个包的若干分片中，该值是相同的 标志(flag):
占3位,目前只有后两位有意义,分别为DF和MF。 DF：
Don’t Fragment 中间的一位，只有当 DF=0 时才允许分片 MF：
More Fragment 最后一位，MF=1表示后面还有分片,MF=0 表示最后一个分片 片偏移:
占12位,指较长的分组在分片后，该分片在原分组中的相对位置.片偏移以8个字节为偏移单位 生存时间:
占8位,记为TTL (Time To Live) 数据报在网络中可通过的路由器数的最大值,TTL 字段是由发送端初始设置一个8bit字段.推荐的初始值由分配数字RFC指定,当前值为64.发送ICMP回显应答时经常把TTL设为最大值255。 协议:
占8位,指出此数据报携带的数据使用何种协议以便目的主机的IP层将数据部分上交给哪个处理过程, 1表示为ICMP协议, 2表示为IGMP协议, 6表示为TCP协议,17表示为UDP协议 首部检验和:
占16位,只检验数据报的首部不检验数据部分.这里不采用 CRC 检验码而采用简单的计算方法 源地址和目的地址:
都各占4字节,分别记录源地址和目的地址
[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/ip_default_ttl #查看Linux默认的TTL 64 [root@node101.yinzhengjie.org.cn ~]# [root@node101.yinzhengjie.org.cn ~]# echo 128 > /proc/sys/net/ipv4/ip_default_ttl #我们将Linux的TTL修改成和Windows一样的TTL，这样别人ping咱们Linux服务器默认还以为咱们使用的是windows呢~ [root@node101.yinzhengjie.org.cn ~]# [root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/ip_default_ttl 128 [root@node101.yinzhengjie.org.cn ~]# [root@node101.yinzhengjie.org.cn ~]#
[root@node102.yinzhengjie.org.cn ~]# ping -c 10 172.30.1.101 #使用Linux默认的TTL，ping该机器观察ttl的值。 PING 172.30.1.101 (172.30.1.101) 56(84) bytes of data. 64 bytes from 172.30.1.101: icmp_seq=1 ttl=64 time=0.289 ms 64 bytes from 172.30.1.101: icmp_seq=2 ttl=64 time=0.555 ms 64 bytes from 172.30.1.101: icmp_seq=3 ttl=64 time=0.360 ms 64 bytes from 172.30.1.101: icmp_seq=4 ttl=64 time=0.284 ms 64 bytes from 172.30.1.101: icmp_seq=5 ttl=64 time=0.302 ms 64 bytes from 172.30.1.101: icmp_seq=6 ttl=64 time=0.302 ms 64 bytes from 172.30.1.101: icmp_seq=7 ttl=64 time=0.685 ms 64 bytes from 172.30.1.101: icmp_seq=8 ttl=64 time=0.809 ms 64 bytes from 172.30.1.101: icmp_seq=9 ttl=64 time=0.691 ms 64 bytes from 172.30.1.101: icmp_seq=10 ttl=64 time=0.385 ms --- 172.30.1.101 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9007ms rtt min/avg/max/mdev = 0.284/0.466/0.809/0.190 ms [root@node102.yinzhengjie.org.cn ~]# [root@node102.yinzhengjie.org.cn ~]# ping -c 10 172.30.1.101 #由于我上面将该机器的TTL修改为128，再次去ping观察ttl的值。 PING 172.30.1.101 (172.30.1.101) 56(84) bytes of data. 64 bytes from 172.30.1.101: icmp_seq=1 ttl=128 time=0.217 ms 64 bytes from 172.30.1.101: icmp_seq=2 ttl=128 time=0.322 ms 64 bytes from 172.30.1.101: icmp_seq=3 ttl=128 time=0.437 ms 64 bytes from 172.30.1.101: icmp_seq=4 ttl=128 time=0.534 ms 64 bytes from 172.30.1.101: icmp_seq=5 ttl=128 time=0.757 ms 64 bytes from 172.30.1.101: icmp_seq=6 ttl=128 time=0.401 ms 64 bytes from 172.30.1.101: icmp_seq=7 ttl=128 time=0.726 ms 64 bytes from 172.30.1.101: icmp_seq=8 ttl=128 time=0.285 ms 64 bytes from 172.30.1.101: icmp_seq=9 ttl=128 time=0.750 ms 64 bytes from 172.30.1.101: icmp_seq=10 ttl=128 time=0.443 ms --- 172.30.1.101 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9008ms rtt min/avg/max/mdev = 0.217/0.487/0.757/0.188 ms [root@node102.yinzhengjie.org.cn ~]#
6>.IP PDU 报头示例
片偏移以8个字节为偏移单位，假定MTU=1500 三个包标识 ID都相同，三个包DF都为0，前两个MF=1，最后一个MF=0
7>.IP报文头部协议域
[root@node102.yinzhengjie.org.cn ~]# cat /etc/protocols #记录了哪个协议对应的数字编号，这个定义是由国际组织IANA来定义的。 # /etc/protocols: # $Id: protocols,v 1.11 2011/05/03 14:45:40 ovasik Exp $ # # Internet (IP) protocols # # from: @(#)protocols 5.1 (Berkeley) 4/17/89 # # Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992). # Last IANA update included dated 2011-05-03 # # See also http://www.iana.org/assignments/protocol-numbers ip 0 IP # internet protocol, pseudo protocol number hopopt 0 HOPOPT # hop-by-hop options for ipv6 icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group management protocol ggp 3 GGP # gateway-gateway protocol ipv4 4 IPv4 # IPv4 encapsulation st 5 ST # ST datagram mode tcp 6 TCP # transmission control protocol cbt 7 CBT # CBT, Tony Ballardie <A.Ballardie@cs.ucl.ac.uk> egp 8 EGP # exterior gateway protocol igp 9 IGP # any private interior gateway (Cisco: for IGRP) bbn-rcc 10 BBN-RCC-MON # BBN RCC Monitoring nvp 11 NVP-II # Network Voice Protocol pup 12 PUP # PARC universal packet protocol argus 13 ARGUS # ARGUS emcon 14 EMCON # EMCON xnet 15 XNET # Cross Net Debugger chaos 16 CHAOS # Chaos udp 17 UDP # user datagram protocol mux 18 MUX # Multiplexing protocol dcn 19 DCN-MEAS # DCN Measurement Subsystems hmp 20 HMP # host monitoring protocol prm 21 PRM # packet radio measurement protocol xns-idp 22 XNS-IDP # Xerox NS IDP trunk-1 23 TRUNK-1 # Trunk-1 trunk-2 24 TRUNK-2 # Trunk-2 leaf-1 25 LEAF-1 # Leaf-1 leaf-2 26 LEAF-2 # Leaf-2 rdp 27 RDP # "reliable datagram" protocol irtp 28 IRTP # Internet Reliable Transaction Protocol iso-tp4 29 ISO-TP4 # ISO Transport Protocol Class 4 netblt 30 NETBLT # Bulk Data Transfer Protocol mfe-nsp 31 MFE-NSP # MFE Network Services Protocol merit-inp 32 MERIT-INP # MERIT Internodal Protocol dccp 33 DCCP # Datagram Congestion Control Protocol 3pc 34 3PC # Third Party Connect Protocol idpr 35 IDPR # Inter-Domain Policy Routing Protocol xtp 36 XTP # Xpress Tranfer Protocol ddp 37 DDP # Datagram Delivery Protocol idpr-cmtp 38 IDPR-CMTP # IDPR Control Message Transport Proto tp++ 39 TP++ # TP++ Transport Protocol il 40 IL # IL Transport Protocol ipv6 41 IPv6 # IPv6 encapsulation sdrp 42 SDRP # Source Demand Routing Protocol ipv6-route 43 IPv6-Route # Routing Header for IPv6 ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6 idrp 45 IDRP # Inter-Domain Routing Protocol rsvp 46 RSVP # Resource ReSerVation Protocol gre 47 GRE # Generic Routing Encapsulation dsr 48 DSR # Dynamic Source Routing Protocol bna 49 BNA # BNA esp 50 ESP # Encap Security Payload ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6 (not in official list) ah 51 AH # Authentication Header ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6 (not in official list) i-nlsp 52 I-NLSP # Integrated Net Layer Security TUBA swipe 53 SWIPE # IP with Encryption narp 54 NARP # NBMA Address Resolution Protocol mobile 55 MOBILE # IP Mobility tlsp 56 TLSP # Transport Layer Security Protocol skip 57 SKIP # SKIP ipv6-icmp 58 IPv6-ICMP # ICMP for IPv6 ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6 ipv6-opts 60 IPv6-Opts # Destination Options for IPv6 # 61 # any host internal protocol cftp 62 CFTP # CFTP # 63 # any local network sat-expak 64 SAT-EXPAK # SATNET and Backroom EXPAK kryptolan 65 KRYPTOLAN # Kryptolan rvd 66 RVD # MIT Remote Virtual Disk Protocol ippc 67 IPPC # Internet Pluribus Packet Core # 68 # any distributed file system sat-mon 69 SAT-MON # SATNET Monitoring visa 70 VISA # VISA Protocol ipcv 71 IPCV # Internet Packet Core Utility cpnx 72 CPNX # Computer Protocol Network Executive cphb 73 CPHB # Computer Protocol Heart Beat wsn 74 WSN # Wang Span Network pvp 75 PVP # Packet Video Protocol br-sat-mon 76 BR-SAT-MON # Backroom SATNET Monitoring sun-nd 77 SUN-ND # SUN ND PROTOCOL-Temporary wb-mon 78 WB-MON # WIDEBAND Monitoring wb-expak 79 WB-EXPAK # WIDEBAND EXPAK iso-ip 80 ISO-IP # ISO Internet Protocol vmtp 81 VMTP # Versatile Message Transport secure-vmtp 82 SECURE-VMTP # SECURE-VMTP vines 83 VINES # VINES ttp 84 TTP # TTP nsfnet-igp 85 NSFNET-IGP # NSFNET-IGP dgp 86 DGP # Dissimilar Gateway Protocol tcf 87 TCF # TCF eigrp 88 EIGRP # Enhanced Interior Routing Protocol (Cisco) ospf 89 OSPFIGP # Open Shortest Path First IGP sprite-rpc 90 Sprite-RPC # Sprite RPC Protocol larp 91 LARP # Locus Address Resolution Protocol mtp 92 MTP # Multicast Transport Protocol ax.25 93 AX.25 # AX.25 Frames ipip 94 IPIP # Yet Another IP encapsulation micp 95 MICP # Mobile Internetworking Control Pro. scc-sp 96 SCC-SP # Semaphore Communications Sec. Pro. etherip 97 ETHERIP # Ethernet-within-IP Encapsulation encap 98 ENCAP # Yet Another IP encapsulation # 99 # any private encryption scheme gmtp 100 GMTP # GMTP ifmp 101 IFMP # Ipsilon Flow Management Protocol pnni 102 PNNI # PNNI over IP pim 103 PIM # Protocol Independent Multicast aris 104 ARIS # ARIS scps 105 SCPS # SCPS qnx 106 QNX # QNX a/n 107 A/N # Active Networks ipcomp 108 IPComp # IP Payload Compression Protocol snp 109 SNP # Sitara Networks Protocol compaq-peer 110 Compaq-Peer # Compaq Peer Protocol ipx-in-ip 111 IPX-in-IP # IPX in IP vrrp 112 VRRP # Virtual Router Redundancy Protocol pgm 113 PGM # PGM Reliable Transport Protocol # 114 # any 0-hop protocol l2tp 115 L2TP # Layer Two Tunneling Protocol ddx 116 DDX # D-II Data Exchange iatp 117 IATP # Interactive Agent Transfer Protocol stp 118 STP # Schedule Transfer srp 119 SRP # SpectraLink Radio Protocol uti 120 UTI # UTI smp 121 SMP # Simple Message Protocol sm 122 SM # SM ptp 123 PTP # Performance Transparency Protocol isis 124 ISIS # ISIS over IPv4 fire 125 FIRE crtp 126 CRTP # Combat Radio Transport Protocol crudp 127 CRUDP # Combat Radio User Datagram sscopmce 128 SSCOPMCE iplt 129 IPLT sps 130 SPS # Secure Packet Shield pipe 131 PIPE # Private IP Encapsulation within IP sctp 132 SCTP # Stream Control Transmission Protocol fc 133 FC # Fibre Channel rsvp-e2e-ignore 134 RSVP-E2E-IGNORE mobility-header 135 Mobility-Header # Mobility Header udplite 136 UDPLite mpls-in-ip 137 MPLS-in-IP manet 138 manet # MANET Protocols hip 139 HIP # Host Identity Protocol shim6 140 Shim6 # Shim6 Protocol wesp 141 WESP # Wrapped Encapsulating Security Payload rohc 142 ROHC # Robust Header Compression # 143-252 Unassigned [IANA] # 253 Use for experimentation and testing [RFC3692] # 254 Use for experimentation and testing [RFC3692] # 255 Reserved [IANA] [root@node102.yinzhengjie.org.cn ~]# [root@node102.yinzhengjie.org.cn ~]# [root@node102.yinzhengjie.org.cn ~]# [root@node102.yinzhengjie.org.cn ~]# cat /etc/protocols | wc -l 162 [root@node102.yinzhengjie.org.cn ~]# [root@node102.yinzhengjie.org.cn ~]#
8>.IP地址详解
博主推荐阅读： https://www.cnblogs.com/yinzhengjie/p/11854562.html
五.主机到主机的包传递（数据包的通讯过程，其实抓个包就知道了，下图画的就比较人性化而且忽略了路由,ARP,DNS,实际情况可能比较复杂，比如涉及到HTTP请求过程）
1>.客户端发送SYN给服务端
2>.客户端开始编写部分数据包报文
3>.编写帧报文需要目标地址的mac，检查客户端主机的ARP表，查询是否有对应的记录关系
4>.将自己的mac地址封装
5>.开始ARP广播以获得对端的mac地址
6>.目标服务端收到广播
7>.收到数据帧后进行拆解
8>.将接收到的结果(源地址及MAC信息)添加到当前操作系统
9>.开始编写数据帧想要告诉对方自己的mac地址
10>.将自己编写的数据帧发送给对端主机进行响应
11>.等待接收ARP消息
12>.从广播中捕捉到属于当前主机的消息
13>.将收到的消息解封装之后把对应的IP及mac添加到操作系统中的ARP表
14>.将获取到的目标MAC地址继续编写数据帧并发送
15>.目标主机接收到数据帧后进行拆封获取到SYN信息
16>.收到SYN信息后开始响应对方，发送ACK来建立连接
17>.客户端收到服务端响应的ACK消息
18>.客户端收到消息后需要响应服务端0
19>.TCP三次握手建立成功
20>.客户端开始发送数据
21>.服务端接收到数据
22>.继续响应客户端说自己接收到数据
当你的才华还撑不起你的野心的时候，你就应该静下心来学习。当你的能力还驾驭不了你的目标的时候，你就应该沉下心来历练。问问自己，想要怎样的人生。
欢迎交流学习技术交流，个人微信: "JasonYin2020"（添加时请备注来源及意图备注）
作者: 尹正杰, 博客: https://www.cnblogs.com/yinzhengjie/p/11854107.html
