计算机网络基础之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个比特位，就会出现序列号回绕，再次从开始确认号(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=，ACK=0时，表示这是一个请求建立连接的报文段；当SYN=，ACK=1时，表示对方同意建立连接。SYN=，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段FIN：
表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果FIN=，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段窗口大小：
表示现在允许对方发送的数据量，也就是告诉对方，从本报文段的确认号开始允许对方发送的数据量，达到此值，需要ACK确认后才能再继续传送后面数据，由Window size value * Window size scaling factor（此值在三次握手阶段TCP选项Window scale协商得到）得出此值校验和：
提供额外的可靠性紧急指针：
标记紧急数据在数据字段中的位置选项部分：
其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，选项部分最长为：(^-)*-=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/。若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:(TCP)
TELNET:(TCP)
HTTTP:(TCP)
DNS:(TCP,UDP)
TFTP:(UDP)
SNMP:(UDP)

4>.TCP协议PORT

传输层通过port号，确定应用层协议Port number:
tcp：传输控制协议，面向连接的协议；通信前需要建立虚拟链路；结束后拆除链路
-
udp：User Datagram Protocol，无连接的协议
-IANA:互联网数字分配机构（负责域名，数字资源，协议分配）
-：系统端口或特权端口(仅管理员可用) ，众所周知，永久的分配给固定的系统应用使用，/tcp(ssh), /tcp(http), /tcp(https)
-：用户端口或注册端口，但要求并不严格，分配给程序注册为某应用使用，/tcp(SqlServer), /tcp(oracle),/tcp(mysql),/tcp/udp (memcached)
-：动态端口或私有端口，客户端程序随机使用的端口
其范围的定义：/proc/sys/net/ipv4/ip_local_port_range

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/ip_local_port_range[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/ip_local_port_range

5>.TCP三次握手

client端首先发送一个SYN包(在建立连接时使用，用来同步序号)告诉server端我的初始序列号是Xclient端收到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-
主动关闭,主机已发送关闭连接请求，等待对方确认FIN-WAIT-
主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭传输连接请求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系统调用可能因为如下两个原因失败返回：
、如果connect连接的目标端口不存在（未被任何进程监听），或者该端口仍被处于TIME_WAIT状态的连接所占用（见后文），则服务器将给客户端发送一个复位报文段，connect调用失败。
、如果目标端口存在，但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[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_max_orphans

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout

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[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_max_syn_backlog

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/core/somaxconn[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/core/somaxconn

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[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_retries1

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_retries2[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_retries2

14>.TCP确认

15>.固定窗口

16>.TCP滑动窗口

17>.拥塞控制

网络中的带宽、交换结点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可承受的能力，网络的性能就会变坏。此情况称为拥塞
TCP为提高网络利用率，降低丢包率，并保证网络资源对每条数据流的公平性。即所谓的拥塞控制
TCP拥塞控制的标准文档是RFC ，其中详细介绍了拥塞控制的四个部分：慢启动（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 ~]#

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/tcp_congestion_control

三.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包的类型为""则表示request请求报文，如果类型为""则表示reply回应报文。因此我们可以根据这个特点在服务器端配置相应的策略来实现禁ping的效果。在Linux系统中，除了上面所说的根据ICMP报文类型编写相应的防火墙策略来实现禁ping的效果，其实也可以直接关闭一个内核参数就可以轻松实现禁ping:
[root@node101.yinzhengjie.org.cn ~]# echo > /proc/sys/net/ipv4/icmp_echo_ignore_all

[root@node102.yinzhengjie.org.cn ~]# ping -c 172.30.1.101#指定ping的次数为10次
PING 172.30.1.101 (172.30.1.101) () bytes of data.
bytes from 172.30.1.101: icmp_seq= ttl= time=0.344 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.531 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.316 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.302 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.374 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.287 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.790 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.314 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.624 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.799 ms--- 172.30.1.101 ping statistics ---
packets transmitted, received, % 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 172.30.1.101#指定ping的次数为10次

[root@node102.yinzhengjie.org.cn ~]# ping -c -w 172.30.1.101#无论是否ping通，只ping一次
PING 172.30.1.101 (172.30.1.101) () bytes of data.
bytes from 172.30.1.101: icmp_seq= ttl= time=0.367 ms--- 172.30.1.101 ping statistics ---
packets transmitted, received, % 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 172.30.1.101
PING 172.30.1.101 (172.30.1.101) () bytes of data.
bytes from 172.30.1.101: icmp_seq= ttl= time=0.386 ms--- 172.30.1.101 ping statistics ---
packets transmitted, received, % 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 -c 10 -w 1 172.30.1.101#无论是否ping通，只ping一次

[root@node102.yinzhengjie.org.cn ~]# ping -s 172.30.1.101 -c #指定ICMP数据为5000字节
PING 172.30.1.101 (172.30.1.101) () bytes of data.
bytes from 172.30.1.101: icmp_seq= ttl= time=0.253 ms--- 172.30.1.101 ping statistics ---
packets transmitted, received, % 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@node102.yinzhengjie.org.cn ~]# ping -s 5000 172.30.1.101 -c 1 #指定ICMP数据为5000字节

[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 bytes
::40.069101 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length
::40.069116 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: icmp
::40.069118 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: icmp
::40.069120 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: icmp
::40.069135 IP node101.yinzhengjie.org.cn > node102.yinzhengjie.org.cn: ICMP echo reply, id , seq , length
::40.069149 IP node101.yinzhengjie.org.cn > node102.yinzhengjie.org.cn: icmp
::40.069156 IP node101.yinzhengjie.org.cn > node102.yinzhengjie.org.cn: icmp
::40.069163 IP node101.yinzhengjie.org.cn > node102.yinzhengjie.org.cn: icmp

[root@node101.yinzhengjie.org.cn ~]# tcpdump -i enp0s8 icmp #使用tcpdump之抓取ICMP协议的包。

[root@node102.yinzhengjie.org.cn ~]# ping -s 192.168.124.14 -f#其实我们也可以使用ping发起flood ping攻击。可以ping一下自己的网卡地址，打开操作系统的任务管理器，观察网卡的使用情况。
PING 192.168.124.14 (192.168.124.14) () bytes of data.
.................................................................................................................................................
...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................^X.^@...........................................^C--- 192.168.124.14 ping statistics ---
packets transmitted, received, % packet loss, time 42199ms[root@node102.yinzhengjie.org.cn ~]#

[root@node102.yinzhengjie.org.cn ~]# ping -s 65507 192.168.124.14 -f#其实我们也可以使用ping发起flood ping攻击。如果XP系统的话消耗的是CPU，如果是XP系统之上消耗的是网卡使用率。这也是DOS攻击的方式之一，当然在生成环境中一般情况下是多台肉鸡同时攻击一台服务器，即DDOS，然而黑客能攻击手段每秒可达到TB级别的（如果你公司购买的流量是TB级别的那真的的很有钱啊）。网络安全我们运维人员不得忽略啊！

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/icmp_echo_ignore_all [root@node101.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]# echo > /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 [root@node101.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all #禁ping

[root@node102.yinzhengjie.org.cn ~]# ping -c 172.30.1.101#由于上面已经警ping了，可以ping10次
PING 172.30.1.101 (172.30.1.101) () bytes of data.--- 172.30.1.101 ping statistics ---
packets transmitted, received, % packet loss, time 9004ms[root@node102.yinzhengjie.org.cn ~]#

[root@node102.yinzhengjie.org.cn ~]# ping -c 10 172.30.1.101#由于上面已经警ping了，可以ping10次，并在服务器端使用tcpdump工具。

[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 bytes
::29.524064 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length
::30.523441 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length
::31.524017 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length
::32.524016 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length
::33.524429 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length
::34.525335 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length
::35.525509 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length
::36.526486 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length
::37.527528 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length
::38.528448 IP node102.yinzhengjie.org.cn > node101.yinzhengjie.org.cn: ICMP echo request, id , seq , length

[root@node101.yinzhengjie.org.cn ~]# tcpdump -i enp0s8 icmp #我们发现只接收到了request请求

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 ---fa-b2-5b 动态
192.168.30.255 ff-ff-ff-ff-ff-ff 静态
224.0.0.2 --5e--- 静态
224.0.0.22 --5e--- 静态
224.0.0.251 --5e---fb 静态
224.0.0.252 --5e---fc 静态
239.255.255.250 --5e-7f-ff-fa 静态
255.255.255.255 ff-ff-ff-ff-ff-ff 静态接口: 172.30.1.254 --- 0xf
Internet 地址物理地址类型
172.30.1.101 ---c1-c7- 动态
172.30.1.102 ---1d-d2- 动态
172.30.1.255 ff-ff-ff-ff-ff-ff 静态
224.0.0.2 --5e--- 静态
224.0.0.22 --5e--- 静态
224.0.0.251 --5e---fb 静态
224.0.0.252 --5e---fc 静态
239.255.255.250 --5e-7f-ff-fa 静态接口: 172.30.1.1 --- 0x10
Internet 地址物理地址类型
172.30.1.255 ff-ff-ff-ff-ff-ff 静态
224.0.0.2 --5e--- 静态
224.0.0.22 --5e--- 静态
224.0.0.251 --5e---fb 静态
224.0.0.252 --5e---fc 静态
239.255.255.250 --5e-7f-ff-fa 静态接口: 192.168.124.14 --- 0x15
Internet 地址物理地址类型
192.168.124.1 --a9-ce-c6- 动态
192.168.124.255 ff-ff-ff-ff-ff-ff 静态
224.0.0.2 --5e--- 静态
224.0.0.22 --5e--- 静态
224.0.0.251 --5e---fb 静态
224.0.0.252 --5e---fc 静态
239.255.255.250 --5e-7f-ff-fa 静态
255.255.255.255 ff-ff-ff-ff-ff-ff 静态C:\Users\yinzhengjie>
C:\Users\yinzhengjie>

C:\Users\yinzhengjie>arp -a#Windows查看ARP列表

[root@node101.yinzhengjie.org.cn ~]# arp -n#Linux查看ARP列表
Address HWtype HWaddress Flags Mask Iface
172.30.1.254 ether 0a:::::0f C enp0s8
10.0.2.2 ether ::::: C enp0s3
172.30.1.102 ether :::1d:d2: C enp0s8
[root@node101.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# arp -n #Linux查看ARP列表

[root@node101.yinzhengjie.org.cn ~]# ip neigh#Linux查看ARP列表方式二
172.30.1.254 dev enp0s8 lladdr 0a:::::0f DELAY
10.0.2.2 dev enp0s3 lladdr ::::: STALE
172.30.1.102 dev enp0s8 lladdr :::1d:d2: STALE
[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# ip neigh#Linux查看ARP列表方式二

3>.反向ARP

反向ARP是根据源设备MAC地址通过广播获取IP地址的过程的地址解析协议。

4>.Internet 协议特征

运行于 OSI 网络层面向无连接的协议独立处理数据包分层编址尽力而为传输无数据恢复功能

5>.IP PDU 报头

IP报文头部信息如下图所示:
版本:
占4位,指 IP 协议的版本目前的IP协议版本号为4
首部长度:
占4位,可表示的最大数值是15个单位，一个单位为4字节，因此IP 的首部长度的最大值是60字节
区分服务:
占8位,用来获得更好的服务,在旧标准中叫做服务类型,但实际上一直未被使用过.后改名为区分服务.只有在使用区分服务(DiffServ)时,这个字段才起作用.一般的情况下不使用
总长度:
占16位,指首部和数据之和的长度,单位为字节,因此数据报的最大长度为字节.总长度必须不超过最大传送单元 MTU
标识:
占16位,它是一个计数器,通常，每发送一个报文，该值会加1，也用于数据包分片，在同一个包的若干分片中，该值是相同的
标志(flag):
占3位,目前只有后两位有意义,分别为DF和MF。
DF：
Don’t Fragment 中间的一位，只有当 DF= 时才允许分片
MF：
More Fragment 最后一位，MF=1表示后面还有分片,MF= 表示最后一个分片
片偏移:
占12位,指较长的分组在分片后，该分片在原分组中的相对位置.片偏移以8个字节为偏移单位
生存时间:
占8位,记为TTL (Time To Live) 数据报在网络中可通过的路由器数的最大值,TTL 字段是由发送端初始设置一个bit字段.推荐的初始值由分配数字RFC指定,当前值为.发送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[root@node101.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]# echo > /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 [root@node101.yinzhengjie.org.cn ~]#
[root@node101.yinzhengjie.org.cn ~]#

[root@node101.yinzhengjie.org.cn ~]# cat /proc/sys/net/ipv4/ip_default_ttl #查看Linux默认的TTL

[root@node102.yinzhengjie.org.cn ~]# ping -c 172.30.1.101 #使用Linux默认的TTL，ping该机器观察ttl的值。
PING 172.30.1.101 (172.30.1.101) () bytes of data.
bytes from 172.30.1.101: icmp_seq= ttl= time=0.289 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.555 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.360 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.284 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.302 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.302 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.685 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.809 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.691 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.385 ms--- 172.30.1.101 ping statistics ---
packets transmitted, received, % 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 172.30.1.101 #由于我上面将该机器的TTL修改为128，再次去ping观察ttl的值。
PING 172.30.1.101 (172.30.1.101) () bytes of data.
bytes from 172.30.1.101: icmp_seq= ttl= time=0.217 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.322 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.437 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.534 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.757 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.401 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.726 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.285 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.750 ms
bytes from 172.30.1.101: icmp_seq= ttl= time=0.443 ms--- 172.30.1.101 ping statistics ---
packets transmitted, received, % packet loss, time 9008ms
rtt min/avg/max/mdev = 0.217/0.487/0.757/0.188 ms
[root@node102.yinzhengjie.org.cn ~]#

[root@node102.yinzhengjie.org.cn ~]# ping -c 10 172.30.1.101 #使用Linux默认的TTL，ping该机器观察ttl的值。

6>.IP PDU 报头示例

片偏移以8个字节为偏移单位，假定MTU=三个包标识 ID都相同，三个包DF都为0，前两个MF=，最后一个MF=0

7>.IP报文头部协议域

[root@node102.yinzhengjie.org.cn ~]# cat /etc/protocols #记录了哪个协议对应的数字编号，这个定义是由国际组织IANA来定义的。
# /etc/protocols:
# $Id: protocols,v 1.11 // :: ovasik Exp $
#
# Internet (IP) protocols
#
# from: @(#)protocols 5.1 (Berkeley) //
#
# Updated for NetBSD based on RFC , Assigned Numbers (July ).
# Last IANA update included dated --
#
# See also http://www.iana.org/assignments/protocol-numbersip IP # internet protocol, pseudo protocol number
hopopt HOPOPT # hop-by-hop options for ipv6
icmp ICMP # internet control message protocol
igmp IGMP # internet group management protocol
ggp GGP # gateway-gateway protocol
ipv4 IPv4 # IPv4 encapsulation
st ST # ST datagram mode
tcp TCP # transmission control protocol
cbt CBT # CBT, Tony Ballardie <A.Ballardie@cs.ucl.ac.uk>
egp EGP # exterior gateway protocol
igp IGP # any private interior gateway (Cisco: for IGRP)
bbn-rcc BBN-RCC-MON # BBN RCC Monitoring
nvp NVP-II # Network Voice Protocol
pup PUP # PARC universal packet protocol
argus ARGUS # ARGUS
emcon EMCON # EMCON
xnet XNET # Cross Net Debugger
chaos CHAOS # Chaos
udp UDP # user datagram protocol
mux MUX # Multiplexing protocol
dcn DCN-MEAS # DCN Measurement Subsystems
hmp HMP # host monitoring protocol
prm PRM # packet radio measurement protocol
xns-idp XNS-IDP # Xerox NS IDP
trunk- TRUNK- # Trunk-
trunk- TRUNK- # Trunk-
leaf- LEAF- # Leaf-
leaf- LEAF- # Leaf-
rdp RDP # "reliable datagram" protocol
irtp IRTP # Internet Reliable Transaction Protocol
iso-tp4 ISO-TP4 # ISO Transport Protocol Class
netblt NETBLT # Bulk Data Transfer Protocol
mfe-nsp MFE-NSP # MFE Network Services Protocol
merit-inp MERIT-INP # MERIT Internodal Protocol
dccp DCCP # Datagram Congestion Control Protocol
3pc 3PC # Third Party Connect Protocol
idpr IDPR # Inter-Domain Policy Routing Protocol
xtp XTP # Xpress Tranfer Protocol
ddp DDP # Datagram Delivery Protocol
idpr-cmtp IDPR-CMTP # IDPR Control Message Transport Proto
tp++ TP++ # TP++ Transport Protocol
il IL # IL Transport Protocol
ipv6 IPv6 # IPv6 encapsulation
sdrp SDRP # Source Demand Routing Protocol
ipv6-route IPv6-Route # Routing Header for IPv6
ipv6-frag IPv6-Frag # Fragment Header for IPv6
idrp IDRP # Inter-Domain Routing Protocol
rsvp RSVP # Resource ReSerVation Protocol
gre GRE # Generic Routing Encapsulation
dsr DSR # Dynamic Source Routing Protocol
bna BNA # BNA
esp ESP # Encap Security Payload
ipv6-crypt IPv6-Crypt # Encryption Header for IPv6 (not in official list)
ah AH # Authentication Header
ipv6-auth IPv6-Auth # Authentication Header for IPv6 (not in official list)
i-nlsp I-NLSP # Integrated Net Layer Security TUBA
swipe SWIPE # IP with Encryption
narp NARP # NBMA Address Resolution Protocol
mobile MOBILE # IP Mobility
tlsp TLSP # Transport Layer Security Protocol
skip SKIP # SKIP
ipv6-icmp IPv6-ICMP # ICMP for IPv6
ipv6-nonxt IPv6-NoNxt # No Next Header for IPv6
ipv6-opts IPv6-Opts # Destination Options for IPv6
# # any host internal protocol
cftp CFTP # CFTP
# # any local network
sat-expak SAT-EXPAK # SATNET and Backroom EXPAK
kryptolan KRYPTOLAN # Kryptolan
rvd RVD # MIT Remote Virtual Disk Protocol
ippc IPPC # Internet Pluribus Packet Core
# # any distributed file system
sat-mon SAT-MON # SATNET Monitoring
visa VISA # VISA Protocol
ipcv IPCV # Internet Packet Core Utility
cpnx CPNX # Computer Protocol Network Executive
cphb CPHB # Computer Protocol Heart Beat
wsn WSN # Wang Span Network
pvp PVP # Packet Video Protocol
br-sat-mon BR-SAT-MON # Backroom SATNET Monitoring
sun-nd SUN-ND # SUN ND PROTOCOL-Temporary
wb-mon WB-MON # WIDEBAND Monitoring
wb-expak WB-EXPAK # WIDEBAND EXPAK
iso-ip ISO-IP # ISO Internet Protocol
vmtp VMTP # Versatile Message Transport
secure-vmtp SECURE-VMTP # SECURE-VMTP
vines VINES # VINES
ttp TTP # TTP
nsfnet-igp NSFNET-IGP # NSFNET-IGP
dgp DGP # Dissimilar Gateway Protocol
tcf TCF # TCF
eigrp EIGRP # Enhanced Interior Routing Protocol (Cisco)
ospf OSPFIGP # Open Shortest Path First IGP
sprite-rpc Sprite-RPC # Sprite RPC Protocol
larp LARP # Locus Address Resolution Protocol
mtp MTP # Multicast Transport Protocol
ax. AX. # AX. Frames
ipip IPIP # Yet Another IP encapsulation
micp MICP # Mobile Internetworking Control Pro.
scc-sp SCC-SP # Semaphore Communications Sec. Pro.
etherip ETHERIP # Ethernet-within-IP Encapsulation
encap ENCAP # Yet Another IP encapsulation
# # any private encryption scheme
gmtp GMTP # GMTP
ifmp IFMP # Ipsilon Flow Management Protocol
pnni PNNI # PNNI over IP
pim PIM # Protocol Independent Multicast
aris ARIS # ARIS
scps SCPS # SCPS
qnx QNX # QNX
a/n A/N # Active Networks
ipcomp IPComp # IP Payload Compression Protocol
snp SNP # Sitara Networks Protocol
compaq-peer Compaq-Peer # Compaq Peer Protocol
ipx-in-ip IPX-in-IP # IPX in IP
vrrp VRRP # Virtual Router Redundancy Protocol
pgm PGM # PGM Reliable Transport Protocol
# # any -hop protocol
l2tp L2TP # Layer Two Tunneling Protocol
ddx DDX # D-II Data Exchange
iatp IATP # Interactive Agent Transfer Protocol
stp STP # Schedule Transfer
srp SRP # SpectraLink Radio Protocol
uti UTI # UTI
smp SMP # Simple Message Protocol
sm SM # SM
ptp PTP # Performance Transparency Protocol
isis ISIS # ISIS over IPv4
fire FIRE
crtp CRTP # Combat Radio Transport Protocol
crudp CRUDP # Combat Radio User Datagram
sscopmce SSCOPMCE
iplt IPLT
sps SPS # Secure Packet Shield
pipe PIPE # Private IP Encapsulation within IP
sctp SCTP # Stream Control Transmission Protocol
fc FC # Fibre Channel
rsvp-e2e-ignore RSVP-E2E-IGNORE
mobility-header Mobility-Header # Mobility Header
udplite UDPLite
mpls-in-ip MPLS-in-IP
manet manet # MANET Protocols
hip HIP # Host Identity Protocol
shim6 Shim6 # Shim6 Protocol
wesp WESP # Wrapped Encapsulating Security Payload
rohc ROHC # Robust Header Compression
# - Unassigned [IANA]
# Use for experimentation and testing [RFC3692]
# Use for experimentation and testing [RFC3692]
# 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[root@node102.yinzhengjie.org.cn ~]#
[root@node102.yinzhengjie.org.cn ~]#