简单介绍网络层、传输层、应用层常用协议。
网络层
IP协议
IP协议(InternetProtocol,互联网协议)
是TCP/IP协议栈中最核心的协议之一,通过IP地址,保证了联网设备的唯一性,实现了网络通信的面向无连接和不可靠的传输功能。
协议头图解
Version(版本号):IP协议版本号。目前只有两个版本:IPv4和IPv6
HeaderLength(IP协议头部长度):IP协议头部的长度,单位字节(32bit)需要这个值是因为任选字段的长度是可变的,这个字段占4bit(最多能表示15个32bit的的字,即4*15=60个字节的首部长度),因此IP头部最多有60字节长度。正常的长度是20字节;如果有额外的IP的options选项,还得加上option的长度。
TypeofService(服务类型):标示包传输优先级。总共8位,是由3个优先权位(不再使用),4个TOS位,1个固定的0组成。
4个TOS位:最新延迟、最大吞吐量、最高可靠性、最小成本,只能4选一。TotalLength(包长度):整个IP包的长度,16位,最大可以标示65536个字节,TotalLength-HeaderLength=数据长度。通过HeaderLength和TotalLength就可以知道数据的起始位置和结束位置。
Identifier(标识符):网络中转发的IP报文的长度可以不同,但如果报文长度超过了数据链路所支持的最大长度,则报文就需要分割成若干个小的片段才能在链路上传输。比如以太网帧中数据最大长度(MTU)为1500字节,大于MTU的都会被分割,被分割的每个包都有相同的一个值,表示这是同一个ip包。
Flag(标志位):标志字段在IP报头中占3位。
- 第1位作为保留;
- 第2位,分段,是否允许分片;(如果不允许分片,包超过了数据连路支持的最大长度,则丢弃该包,返回发送者一个ICMP错误)
- 第3位,更多分段。表示是否最后一个分片。
当目的主机接收到一个IP数据报时,会首先查看该数据报的标识符,并且检查标志位的第3位是置0或置1,以确定是否还有更多的分段。如果还有后续报文,接收主机则将接收到的报文放在缓存直到接收完所有具有相同标识符的数据报,然后再进行重组。
FragmentedOffset(偏移量):当某个IP大包分成多片时,各个分片是不按顺序达到目的地的,IP包根据分片的偏移量进行重组包。(跟TCP原理一样)
(TimetoLive)生存时间:表示数据包经过的路由器个数。如果网络上有些路由器的路由表配置不合理,路由寻址可能会导致死循环,数据包会一直循环传输。IP包发送的时候可以设置一个TTL值,比如TTL=64,没经过一个路由器TTL减1,减到0还没到到目的地,路由器会抛弃这个IP包,并使用一个ICMP消息通知发送方。
Protocal(协议):协议类型1:ICMP,2:IGMP,6:TCP,17:UDP。
HeaderCheckSum(首部校验和):校验IP协议头,判断IP协议头是否正确传输。
SourceAddress(源IP):请求方IP
DistinationAddress(目的IP):响应方IP
Options(可选字段):IP支持很多可选选项
ICMP协议
Internet Control Message Protocol,Internet控制消息协议
介绍
- ICMP属于TCP/IP协议族,用于在IP主机、路由器之间传递控制消息。
- 控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据,但是对于用户数据的传递起着重要的作用。
- ICMP协议与ARP协议不同,ICMP靠IP协议来完成任务,所以ICMP报文中要封装IP头部。它与传输层协议(如TCP和UDP)的目的不同,一般不用来在端系统之间传送数据,不被用户网络程序直接使用,除了想Ping和Tracert这样的诊断程序。
- ICMP的主要作用是主机探测,路由维护,路由选择,流量控制。
- ICMP只能搭配IPv4使用,如果是IPv6的情况下, 需要是用ICMPv6
- ICMP报文通常被IP层或更高层协议(TCP或UDP)使用。ICMP报文是在IP数据报内部传输的。IP协议是不可靠协议,不能保证 IP数据报能够成功的到达目的主机,无法进行差错控制,当遇到IP数据无法访问目标、IP路由器无法按当前的传输速率转发数据包等情况时,会自动发送ICMP消息。
ICMP报文格式
ICMP报文包含在IP数据报中,IP报头在ICMP报文的最前面。一个ICMP报文包括IP报头(至少20字节)、ICMP报头(至少八字节)和ICMP报文(属于ICMP报文的数据部分)。当IP报头中的协议字段值为1时,就说明这是一个ICMP报文。ICMP报头如下图所示。
- 类型:占8位
- 代码:占8位
- 检验和:占16位
说明:ICMP所有报文的前4个字节都是一样的,但是剩下的其他字节则互不相同。其它字段都ICMP报文类型不同而不同。
ICMP报文的前4个字节是统一的格式,共有三个字段:即类型,代码和检验和。
- 8位类型和8位代码字段一起决定了ICMP报文的类型。
- 类型8,代码0:表示回显请求(ping请求)。
- 类型0,代码0:表示回显应答(ping应答)
- 类型11,代码0:超时
- 16位的检验和字段:包括数据在内的整个ICMP数据包的检验和;其计算方法和IP头部检验和的计算方法一样的。
ICMP报文具体分为查询报文和差错报文(对ICMP差错报文有时需要做特殊处理,因此要对其进行区分。如:对ICMP差错报文进行响应时,永远不会生成另一份ICMP差错报文,否则会出现死循环)
ICMP查询报文
ICMP询问报文有四种回送请求和回答,时间戳请求和回答,掩码地址请求和回答,以及路由器询问和通过。
- ICMP回送请求报文是由主机或路由器向一个特定的目的主机发出的询问。收到此报文的机器必须给源主机发送ICMP回送应答报文。这种询问报文用来测试目的站是否可达以及了解其有关状态。
- ICMP时间戳请求允许系统向另一个系统查询当前的时间。该ICMP报文的好处是它提供了毫秒级的分辨率,而利用其他方法从别的主机获取的时间只能提供秒级的分辨率。请求端填写发起时间,然后发送报文。应答系统收到请求报文时填写接收时间戳,在发送应答时填写发送时间戳。大多数的实现是把后面两个字段都设成相同的值。
- 主机使用ICMP地址掩码请求报文可向子网掩码服务器得到某个接口的地址掩码。系统广播它的ICMP请求报文。ICMP报文中的标识符和序列号字段由发送端任意选择设定,这些值在应答中将被返回,这样,发送端就可以把应答与请求进行匹配。
- 主机使用ICMP路由器询问和通过报文可了解连接在本网络上的路由器是否正常工作。主机将路由器询问报文进行广播(或多播)。收到询问报文的一个或几个路由器就使用路由器通过报文广播其路由选择信息。
ping使用的是ICMP的查询报文的请求和回答。
ICMP差错报文
ICMP差错报告报文共有5种
终点不可达:终点不可达分为:网络不可达,主机不可达,协议不可达,端口不可达,需要分片但DF比特已置为1,以及源路由失败等六种情况,其代码字段分别置为0至5。当出现以上六种情况时就向源站发送终点不可达报文。
说明:端口不可达:UDP的规则之一是:如果收到UDP数据报而且目的端口与某个正在使用的进程不相符,那么UDP返回一个ICMP不可达报文。
源站抑制:当路由器或主机由于拥塞而丢弃数据报时,就向源站发送源站抑制报文,使源站知道应当将数据报的发送速率放慢。
时间超过:当路由器收到生存时间为零的数据报时,除丢弃该数据报外,还要向源站发送时间超过报文。当目的站在预先规定的时间内不能收到一个数据报的全部数据报片时,就将已收到的数据报片都丢弃,并向源站发送时间超过报文。
参数问题:当路由器或目的主机收到的数据报的首部中的字段的值不正确时,就丢弃该数据报,并向源站发送参数问题报文。
改变路由(重定向)路由器将改变路由报文发送给主机,让主机知道下次应将数据报发送给另外的路由器。
说明:
以下几种情况都不会导致产生ICMP差错报文
- ICMP差错报文(但是,ICMP查询报文可能会产生ICMP差错报文)
- 目的地址是广播地址或多播地址的IP数据报
- 作为链路层广播的数据报
- 不是IP分片的第一片
- 源地址不是单个主机的数据报。即源地址不能为零地址、环回地址、广播地址或多播地址。
这些规则是为了防止过去允许ICMP差错报文对广播分组响应所带来的广播风暴。
所有的ICMP差错报告报文中的数据字段都具有同样的格式。将收到的需要进行差错报告IP数据报的首部和数据字段的前8个字节提取出来,作为ICMP报文的数据字段。再加上响应的ICMP差错报告报文的前8个字节,就构成了ICMP差错报告报文。提取收到的数据报的数据字段的前8个字节是为了得到运输层的端口号(对于TCP和UDP)以及运输层报文的发送序号(对于TCP)。一般情况下不发送ICMP差错报告报文。
IGMP协议
Internet Group Management Protocol,Internet组管理协议
介绍
IGMP也是IP协议的一个补充,位于TCP/IP体系中的网络层,是用于管理网路协议多播组成员的一种通信协议。
该协议用来在ip主机和与其直接相邻的组播路由器之间建立、维护组播组成员关系,但不包括组播路由器之间的组成员关系信息的传播与维护,这部分工作由各组播路由协议完成。所有参与组播的主机必须实现IGMP。
GMP目前有三个版本,目前用的最多的是IGMPv2。
- IGMPv1主要基于查询和响应机制来完成对组播组成员的管理;
- IGMPv2增加了查询器选举机制和离开组机制;
- IGMPv3在兼容和继承IGMPv1和IGMPv2的基础上,进一步增强了主机的控制能力,并增强了查询和报告报文的功能;
IGMP报文格式
IGMPv1
4位版本:目前IGMP有V1,V2,V3三个版本,比如是V1则该4位为1, V3则该4位为3。
4位类型:成员关系查询0x11和成员关系报告0x12两种类型。
16位校验和:8个字节的校验码。
32位组地址:
- 当发送报文是成员关系报告时,该32位组地址即组播组地址。
- 当发送的报文是成员关系查询时,该32位为全0。V1版本只支持通用关系查询,不支持特定组查询。
IGMPv2
- 8位类型:有三种类型;
- 成员关系查询0x11:在V2和V3中成员关系查询增加特定组查询:
- 常规查询:用于确定哪些组播组是活跃的,即改组是否还有成员在使用,常规查询组地址由全零表示。
- 特定组查询:用于查询某具体组播组是否还有组成员。
- 成员关系报告0x16(版本1成员关系报告0x12);
- 离开组消息0x17;
- 成员关系查询0x11:在V2和V3中成员关系查询增加特定组查询:
- 8位最大响应时间:以0.1秒为单位,默认值是100,即10秒。
- 16位校验和:报文段8个字节的校验码。
- 32位组地址:
- 成员关系查询报文:常规查询组低位为全0,特定组查询则应设置对应的组地址;
- 成员报告或离开组消息:组地址为要报告或要离开的组地址;
- 8位类型:有三种类型;
三种协议比较
IGMP协议功能
加入一个多播组
多播的基础就是一个进程的概念(使用的术语进程是指操作系统执行的一个程序),该进程在一个主机的给定接口上加入了一个多播组。在一个给定接口上的多播组中的成员是动态的,它随时因进程加入和离开多播组而变化。
这里所指的进程必须以某种方式在给定的接口上加入某个多播组。进程也能离开先前加入的多播组。这些是一个支持多播主机中任何API所必需的部分。使用限定词“接口”是因为多播组中的成员是与接口相关联的。一个进程可以在多个接口上加入同一多播组。
IGMP报告和查询
多播路由器使用IGMP报文来记录与该路由器相连网络中组成员的变化情况。使用规则如下:
- 当第一个进程加入一个组时,主机就发送一个IGMP报告。如果一个主机的多个进程加入同一组,只发送一个IGMP报告。这个报告被发送到进程加入组所在的同一接口上。
- 进程离开一个组时,主机不发送IGMP报告,即便是组中的最后一个进程离开。主机知道在确定的组中已不再有组成员后,在随后收到的IGMP查询中就不再发送报告报文。
- 多播路由器定时发送IGMP查询来了解是否还有任何主机包含有属于多播组的进程。多播路由器必须向每个接口发送一个IGMP查询。因为路由器希望主机对它加入的每个多播组均发回一个报告,因此IGMP查询报文中的组地址被设置为0。
- 主机通过发送IGMP报告来响应一个IGMP查询,对每个至少还包含一个进程的组均要发回IGMP报告。
使用这些查询和报告报文,多播路由器对每个接口保持一个表,表中记录接口上至少还包含一个主机的多播组。当路由器收到要转发的多播数据报时,它只将该数据报转发到(使用相应的多播链路层地址)还拥有属于那个组主机的接口上。
下图显示了两个IGMP报文,一个是主机发送的报告,另一个是路由器发送的查询。该路由器正在要求那个接口上的每个主机说明它加入的每个多播组。
离开报文(仅限IGMPv2和v3)
该报文由主机发出。当主机离开组播组时发送此报文,向组播路由器报告离开了特定的组播组。离开报文的目标IP为224.0.0.2(所有组播路由器),IGMP报头内的组播IP为特定离开组的IP。
IGMP报文种类
ARP协议
Address Resolution Protocol,地址解析协议
功能:把网络层32位的IP转换成数据链路层48位的MAC地址,在这个过程中有一个很重要的表,ARP缓存表。该表的形式如下,也是一个映射;
对于ARP缓存表的使用,有两种情况
ARP缓存表中有缓存IP地址和MAC地址的映射关系
ARP缓存表中没有缓存IP地址和MAC地址的映射关系
如果有缓存的情况,就像上篇文章中介绍的步骤一样,A可以直接告诉数据链路层,E的MAC地址。A会查询ARP缓存表,查看E的MAC地址是什么,然后告知数据链路层。
如果没有缓存的情况,ARP会广播某一个IP的信息,收到这个广播的设备会回应一个包,表示我是不是这个IP地址。如果是,广播该IP地址的设备会记录对应设备的MAC地址
ARP缓存表是ARP协议和RARP协议运行的关键
- ARP缓存表缓存了IP地址到硬件地址之间的映射关系(在网络层进行数据转发的时候,需要数据链路层和物理层,因此网络层在进行数据发送的时候,首先需要通过ARP协议,把IP地址转化为MAC地址,然后告诉数据链路层,这时,数据链路层才能进行数据帧的传输)
- ARP缓存表中的记录并不是永久有效的,有一定的期限(因为MAC地址是永久不变的,但是IP地址是会变化的)
ARP报文格式
ARP协议的报文信息是直接封装到数据链路层的数据帧中的
最上边为数据链路层的数据帧格式,中间是ARP协议的报文信息,PAD是填充的内容
虽然ARP协议是直接封装在数据链路层的数据帧中的,但ARP协议仍属于网络层,主要是因为ARP协议使用到了IP地址,所以它属于网络层的内容。所以ARP协议是数据链路层和网络层配合使用的一个协议。
RARP协议
Reverse Address Resolution Protocol,逆地址解析协议
和ARP协议做相反的工作,它是将48位的MAC地址转换为32位的IP地址
RARP报文格式
传输层
TCP
Transmisson Control Protocol,传输控制协议
介绍
- TCP协议为应用程序提供了稳定可靠的数据传输。它是一个滑动窗口协议,提供了超时和重传的处理。
- TCP 是在两个端点之间建立的全双工虚拟连接。每个端点由 IP 地址和端口号定义。
- 数据以字节流的形式传输,字节流按段传输。窗口大小决定了在需要接收方确认之前可以发送的数据字节数。
- TCP的底层网络层并不是一个可靠服务,它只提供尽最大努力服务。要在一个不可靠的协议上建立一个可靠的协议,TCP采用了发送-确认机制:即接收方每发送一个报文,就向发送方发送一个确认,发送方只有收到这个报文的确认才认为这次发送才是成功的。
TCP报文格式
TCP封装
TCP头格式
- 源端口号/目标端口号 标记TCP连接通信双方主机的端口,而双方的IP地址在IP协议的报文首部中已经记录。端口号最大值为65535
- 32位序号 发送方报文数据段的起始序号,用于标记每一个发送字节;
- 32位确认序号 表示接收方已经成功接收(确认序号-1)的字节。假设B发送给A的TCP报文中,确认需要为700,则表示B已经成功接收了A发送的序号为700之前(不包括700)的所有数据 若确认序号 = N, 则表明:到需要N-1为止的所有数据都已经正确收到
- 4位首部长度 TCP首部前20位是固定的,
选项
部分的长度是可选的,但是长度为4N(即4的倍数)。首部长度代表整个报文首部的长度,单位是4字节(32位)。4位首部长度最大值是15,即TCP报文首部最大长度是15 * 4 = 60 个字节,首部可选长度为 60 - 20 = 40 个字节 - 保留(6位) 保留今后使用,目前置为0
- 6个控制位
- URG: 表明该报文段的紧急指针字段有效,它告诉系统此报文段中有紧急数据,紧急指针指明了紧急数据的最后一个字节位于数据段中哪个序号
- ACK: 仅当ACK=1时,确认序号字段才生效;当ACK=0时,确认序号字段无效。TCP规定,在连接建立后所有传送的TCP报文段都必须把ACK置为1
- PSH: TCP接收方收到PSH=1的报文段时,会尽快的交付到给应用程序处理,而不需要等待整个接收缓存都填满了再向上交付
- RST: 当RST=1时,表明TCP连接出现严重差错,必须断开后重新建立连接,同时可以用于拒绝一个非法报文或拒绝打开一个连接
- SYN:SYN置为1时,表示这是一个连接请求或接受连接报文;
- FIN:用于释放一个连接,当FIN为1时,表示发送方的数据已经发送完毕,并要求释放连接
- 16位窗口大小 接收窗口,窗口值告诉对方,当前报文确认序号算起,接收方允许发送的数据量 接收窗口值是发送发设置其发送窗口的依据,且该值是动态变化的
- 16位校验和 当接收方接收到一个报文段后,会使用该字段校验整个报文是否完整且正确
- 16位紧急指针 与控制位URG搭配使用
- 选项 长度可变,最大可达40字节。可以用于存放:
- 最大报文长度 MSS (maximum segment size)
- 窗口扩大选项:解决高速网络下窗口字段不够用问题
- 时间戳戳选项:用于计算往返时间和防止序号绕回
- 数据 存放要发送的报文数据
UDP
User Data Protocol,用户数据包协议
介绍
UDP(用户数据报协议)是一个简单的面向数据报的传输层协议。提供的是非面向连接的、不可靠的数据流传输。UDP不提供可靠性,也不提供报文到达确认、排序以及流量控制等功能。它只是把应用程序传给IP层的数据报发送出去,但是并不能保证它们能到达目的地。因此报文可能会丢失、重复以及乱序等。但由于UDP在传输数据报前不用在客户和服务器之间建立一个连接,且没有超时重发等机制,故而传输速度很快。DNS解析使用UDP协议
UDP报文格式
- 源端口:这个字段占据 UDP 报文头的前 16 位,通常包含发送数据报的应用程序所使用的 UDP 端口。接收端的应用程序利用这个字段的值作为发送响应的目的地址。这个字段是可选的,所以发送端的应用程序不一定会把自己的端口号写入该字段中。如果不写入端口号,则把这个字段设置为 0。这样,接收端的应用程序就不能发送响应了。
- 目的端口:接收端计算机上 UDP 软件使用的端口,占据 16 位。
- 长度:该字段占据 16 位,表示 UDP 数据报长度,包含 UDP 报文头和 UDP 数据长度。因为 UDP 报文头长度是 8 个字节,所以这个值最小为 8。
- 校验值:该字段占据 16 位,可以检验数据在传输过程中是否被损坏。
应用层
HTTP
Hyper Text Transfer Protocol,超文本传输协议
HTTP是一个基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。
HTTP是一个属于应用层的面向对象的协议,由于其简捷、快速的方式,适用于分布式超媒体信息系统。它于1990年提出,经过几年的使用与发展,得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版,HTTP/1.1的规范化工作正在进行之中,而且HTTP-NG(Next Generation of HTTP)的建议已经提出。
HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后,向客户端发送响应信息。
请求报文
响应报文
常用状态码
状态码 类比 说明 1xx Informational (信息性状态码) 接收的请求正在处理 2xx Success( 成功状态码) 请求正常处理完毕 3xx Redirection( 重定向状态码) 需要进行附加操作以完成请求 4xx Client Error (客户端错误状态码) 服务器无法处理请求 5xx Server Error 服务器错误状态码 服务器处理请求出错 HTTP首部字段
主要分为四种:
通用首部字段
请求报文和响应报文都可以使用的字段,以下是通用字段表:
字段名 说明 Cache-Control 控制缓存行为 Connection 逐跳首部、连接的管理 Date 创建报文的日期时间 Pragma 报文指令 Trailer 报文末端的首部一览 Transfer-Encoding 指定报文主体的传输编码方式 Upgrade 升级为其他协议 Warning 错误通知 Via 代理服务器的相关信息 请求首部字段
请求报文可以使用的字段,以下是请求报文字段表:
字段名 说明 Accept 用户代理可处理的媒体类型 Accept-Charset 优先的字符集 Accept-Encoding 优先的内容编码 Accept-Language 优先的语言(自然语言) Authorizabon Web认证信息 Expect 期待服务器的特定行为 From 用户的电子邮箱地址 Host 请求资源所在服务器 If-Match 比较实体标记(ETag ) If-Modified-Since 比较资源的更新时间 If-None-Match 比较实体标记(与If-Match相反 ) lf-Range 资源未更新时发送实体Byte的范围请求 If-Unmodified-Since 比较资源的更新时间( 与If-Modified-Since 相反I Max-Forwards 最大传输逐跳数 Proxy-Authorization 代理服务器要求客户端的认证信息 Range 实体的字节范围请求 Referer 对请求中URl的原始获取方 TE 传输编码的优先级 User-Agent HTTP客户端程序的信息 响应首部字段
响应报文可以使用的字段,以下是响应报文字段表:
字段名 说明 Accept-Ranges 是否接受字节范围请求 Age 推算资源创建经过时间 ETag 资源的匹配信息 Location 令客户端重定向至指定URI Proxy-Authenticate 代理服务器对客户端的认证信息 Retry-After 对再次发起请求的时机要求 Server HTTP服务器的安装信息 Vary 代理服务器缓存的管理信息 WWW-Authenticate 服务器对客户端的认证信息** 实体首部字段
针对请求报文和响应报文的实体部分使用的首部,主要是补充了实体资源相关信息,以下是实体首部字段表:
字段名 说明 Allow 资源可支持的HTTP方法 Content-Encoding 实体主体适用的编码方式 Content-Language 实体主体的自然语言 Content-Length 实体主体的大小(单位字节) Content-Location 替代对应资源的URI Content-MD5 实体主体的报文摘要 Content-Range 实体主体的位置范围 Content-Type 实体主体的媒体类型 Expires 实体主体过期的日期时间 Last-Modified 资源的最后修改日期时间
未完,抽时间再继续写
FTP
TFTP
TELNET
DNS
SMTP
POP3
IAMP
SNMP
SSL
参考
- https://www.jianshu.com/p/90abebfe0014
- https://www.jianshu.com/p/4bd8758f9fbd
- https://blog.csdn.net/tigerjibo/article/details/7356936
- https://segmentfault.com/a/1190000023255475
- https://juejin.im/post/6844904033354776584
- http://c.biancheng.net/view/6440.html
- https://www.jianshu.com/p/80e25cb1d81a
- https://www.jianshu.com/p/f5b3324b961f