精华内容
下载资源
问答
  • 以太网类型速查(协议字段
    2018-03-30 13:18:00

    EtherType :以太网类型字段及值

    EtherType 是以太帧里的一个字段,用来指明应用于帧数据字段的协议。根据 IEEE802.3,Length/EtherType 字段是两个八字节的字段,含义两者取一,这取决于其数值。在量化评估中,字段中的第一个八位字节是最重要的。而当字段值大于等于十进制值 1536 (即十六进制为 0600)时, EtherType 字段表示为 MAC 客户机协议(EtherType 解释)的种类。该字段的长度和 EtherType 详解是互斥的。
    该类字段值取自 IEEE EtherType 字段寄存器。EtherType 字段是个极限空间,因此其分配是有限的。只有开发新的数据传输协议的人员需要使用 EtherType 字段,而不管他们实际上是否真正生产任何设备。IEEE RAC EtherType 字段批准权威机构负责检查和批准 EtherType 字段。
    知名协议已经分配了 EtherType 值,下面表格中列出了 EtherType 字段中常用值及其对应的协议:
    Ethertype 
    ( 十六进制 ) 
    协议 

    0x0000 - 0x05DC   IEEE 802.3 长度

    0x0101 – 0x01FF   实验

    0x0600   XEROX NS IDP

    0x0660 
    0x0661   DLOG

    0x0800   网际协议(IP)

    0x0801   X.75 Internet

    0x0802   NBS Internet

    0x0803   ECMA Internet

    0x0804   Chaosnet

    0x0805   X.25 Level 3

    0x0806   地址解析协议(ARP : Address Resolution Protocol)

    0x0808   帧中继 ARP (Frame Relay ARP) [RFC1701] 
    0x6559   原始帧中继(Raw Frame Relay) [RFC1701] 
    0x8035   动态 DARP (DRARP:Dynamic RARP)反向地址解析协议(RARP:Reverse Address Resolution Protocol)

    0x8037   Novell Netware IPX 
    0x809B   EtherTalk 
    0x80D5 IBM SNA Services over Ethernet 
    0x 80F 3   AppleTalk 地址解析协议(AARP:AppleTalk Address Resolution Protocol)

    0x8100   以太网自动保护开关(EAPS:Ethernet Automatic Protection Switching)

    0x8137 因特网包交换(IPX:Internet Packet Exchange)

    0x 814C   简单网络管理协议(SNMP:Simple Network Management Protocol)

    0x86DD   网际协议v6 (IPv6,Internet Protocol version 6)

    0x880B   点对点协议(PPP:Point-to-Point Protocol)

    0x 880C   通用交换管理协议(GSMP:General Switch Management Protocol)

    0x8847 
    多协议标签交换(单播) MPLS:Multi-Protocol Label Switching <unicast>)

    0x8848   多协议标签交换(组播)(MPLS, Multi-Protocol Label Switching <multicast>)

    0x8863   以太网上的 PPP(发现阶段)(PPPoE:PPP Over Ethernet <Discovery Stage>)

    0x8864   以太网上的 PPP(PPP 会话阶段) (PPPoE,PPP Over Ethernet<PPP Session Stage>)

    0x88BB 轻量级访问点协议(LWAPP:Light Weight Access Point Protocol)

    0x88CC   链接层发现协议(LLDP:Link Layer Discovery Protocol)

    0x8E88   局域网上的 EAP(EAPOL:EAP over LAN)

    0x9000 配置测试协议(Loopback) 
    0x9100   VLAN 标签协议标识符(VLAN Tag Protocol Identifier)

    0x9200   VLAN 标签协议标识符(VLAN Tag Protocol Identifier)

    0xFFFF   保留

    转载于:https://www.cnblogs.com/laixufie2046/p/8675666.html

    更多相关内容
  • 一系列以太网协议报文格式归纳详解,包括ip tcp udp等协议
  • TCP报文格式: ​ ​ 源端口号和目的端口号: ​ 用于寻找发端和收端应用进程。这两个值加上ip首部源端ip地址和目的端ip地址唯一确定一个tcp连接。 ​ 序号字段: ​ 序号用来标识从T C P发端向T C P收端发送的...

    TCP报文格式:

    源端口号和目的端口号

    ​ 用于寻找发端和收端应用进程。这两个值加上ip首部源端ip地址和目的端ip地址唯一确定一个tcp连接。

    序号字段:

    ​ 序号用来标识从T C P发端向T C P收端发送的数据字节流,它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动,则 T C P用序号对每个字节进行计数。序号是32 bit的无符号数,序号到达 2^32-1后又从0开始。

    当建立一个新的连接时,SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN(Initial Sequence Number)。该主机要发送数据的第一个字节序号为这个ISN加1,因为SYN标志消耗了一个序号

    确认序号

    ​ 既然每个传输的字节都被计数,确认序号包含发送确认的一端所期望收到的下一个序号。因此,确认序号应当是上次已成功收到数据字节序号加 1。只有ACK标志为 1时确认序号字段才有效。发送ACK无需任何代价,因为 32 bit的确认序号字段和A C K标志一样,总是T C P首部的一部分。因此,我们看到一旦一个连接建立起来,这个字段总是被设置, ACK标志也总是被设置为1。TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此,连接的每一端必须保持每个方向上的传输数据序号。

    首都长度

    ​ 首部长度给出首部中 32 bit字的数目。需要这个值是因为任选字段的长度是可变的。这个字段占4 bit,因此T C P最多有6 0字节的首部。然而,没有任选字段,正常的长度是 2 0字节。

    标志字段:在T C P首部中有 6个标志比特。它们中的多个可同时被设置为1.
      URG紧急指针(u rgent pointer)有效
      ACK确认序号有效。
      PSH接收方应该尽快将这个报文段交给应用层。
      RST重建连接。
      SYN同步序号用来发起一个连接。这个标志和下一个标志将在第 1 8章介绍。
      FIN发端完成发送任务。

    窗口大小

    ​ T C P的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数,起始于确认序号字段指明的值,这个值是接收端期望接收的字节。窗口大小是一个 16 bit字段,因而窗口大小最大为 65535字节。

    检验和:

    ​ 检验和覆盖了整个的 T C P报文段:T C P首部和T C P数据。这是一个强制性的字段,一定是由发端计算和存储,并由收端进行验证。

    紧急指针

    ​ 只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量,和序号字段中的值相加表示紧急数据最后一个字节的序号。 T C P的紧急方式是发送端向另一端发送紧急数据的一种方式。

    选项

    ​ 最常见的可选字段是最长报文大小,又称为 MSS (Maximum Segment Size)。每个连接方通常都在通信的第一个报文段(为建立连接而设置 S Y N标志的那个段)中指明这个选项。它指明本端所能接收的最大长度的报文段。



    UDP报文格式:

    端口号

    ​ 用来表示发送和接受进程。由于 I P层已经把I P数据报分配给T C P或U D P(根据I P首部中协议字段值),因此T C P端口号由T C P来查看,而 U D P端口号由UDP来查看。T C P端口号与UDP端口号是相互独立的。

    长度

    ​ UDP长度字段指的是UDP首部和UDP数据的字节长度。该字段的最小值为 8字节(发送一份0字节的UDP数据报是 O K)。

    检验和

    ​ UDP检验和是一个端到端的检验和。它由发送端计算,然后由接收端验证。其目的是为了发现UDP首部和数据在发送端到接收端之间发生的任何改动。



    IP报文格式:

    普通的IP首部长为20个字节,除非含有可选项字段。

    4位版本

    ​ 目前协议版本号是4,因此IP有时也称作IPV4.

    4位首部长度

    ​ 首部长度指的是首部占32bit字的数目,包括任何选项。由于它是一个4比特字段,因此首部长度最长为60个字节。

    服务类型(TOS)

    ​ 服务类型字段包括一个3bit的优先权字段(现在已经被忽略),4bit的TOS子字段和1bit未用位必须置0。4bit的TOS分别代表:最小时延,最大吞吐量,最高可靠性和最小费用。4bit中只能置其中1比特。如果所有4bit均为0,那么就意味着是一般服务。

    总长度

    ​ 总长度字段是指整个IP数据报的长度,以字节为单位。利用首部长度和总长度字段,就可以知道IP数据报中数据内容的起始位置和长度。由于该字段长16bit,所以IP数据报最长可达65535字节。当数据报被分片时,该字段的值也随着变化。

    标识字段

    ​ 标识字段唯一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1。

    生存时间

    ​ TTL(time-to-live)生存时间字段设置了数据报可以经过的最多路由器数。它指定了数据报的生存时间。TTL的初始值由源主机设置(通常为 3 2或6 4),一旦经过一个处理它的路由器,它的值就减去 1。当该字段的值为 0时,数据报就被丢弃,并发送 ICMP 报文通知源主机。

    首部检验和

    ​ 首部检验和字段是根据 I P首部计算的检验和码。它不对首部后面的数据进行计算。 ICMP、IGMP、UDP和TCP在它们各自的首部中均含有同时覆盖首部和数据检验和码。



    以太网报文格式:


    目的地址和源地址:

    ​ 是指网卡的硬件地址(也叫MAC 地址),长度是48 位,是在网卡出厂时固化的。

    数据:

    ​ 以太网帧中的数据长度规定最小46 字节,最大1500 字节,ARP 和RARP 数据包的长度不够46 字节,要在后面补填充位。最大值1500 称为以太网的最大传输单元(MTU),不同的网络类型有不同的MTU,如果一个数据包从以太网路由到拨号链路上,数据包度大于拨号链路的MTU了,则需要对数据包进行分片fragmentation)。ifconfig 命令的输出中也有“MTU:1500”。注意,MTU 个概念指数据帧中有效载荷的最大长度,不包括帧首部的长度。



    人凭的到的东西维持生计,用给予的东西构筑人生……

    展开全文
  • 以太网通讯报文详解

    千次阅读 2022-02-07 10:30:56
    以太网通讯报文详解 来源:编程帮,http://c.biancheng.net/view/6385.html 1、物理层协议有:EIA/TIA-232, EIA/TIA-499,V.35, V.24,RJ45, Ethernet, 802.3 2、数据链路层协议有:Frame Relay,HDLC,PPP, ...

    以太网通讯报文详解

    来源:编程帮,http://c.biancheng.net/view/6385.html
    **加粗样式**
    1、物理层协议有:EIA/TIA-232, EIA/TIA-499,V.35, V.24,RJ45, Ethernet, 802.3
    2、数据链路层协议有:Frame Relay,HDLC,PPP, IEEE 802.3/802.2
    3、网络层协议有:IP,IPX,AppleTalk DDP
    4、传输层协议有:TCP,UDP,SPX,ICMP
    5、会话层协议有:RPC,SQL,NFS,NetBIOS,names,AppleTalk
    6、表示层协议有:TIFF,GIF,JPEG,PICT,ASCII,EBCDIC,encryption
    7、应用层协议有:FTP,WWW,Telnet,NFS,SMTP,Gateway,SNMP,HTTP

    物理层

    详细见:https://www.cnblogs.com/qishui/p/5449783.html
    在这里插入图片描述
    (1)MII(介质无关接口)和RS(协调子层)
    MII:依赖物理层功能和不依赖物理层功能的分界接口
    RS:负责处理MII信令与MAC子层翻译或映射需求的一个特殊子层(相当于物理层顶层)

    (2)PCS(物理编码子层)
    从名称来看,本层将主要从事编码相关工作;
    以CAN总线为例,为了实现同步,CAN总线会在每五个0穿插一个1。
    而在PCS中,则会采用4B/5B编码的方式,来进行转换,来避免常规数据传输过程中产生的不平衡。另外PCS还可以采用加扰的方式,将传输的数据,转化成便于接受的形式。

    (3)PMA(物理媒介附加)——也被称为串行器或者解串器
    本层主要作用是将数据在两种不大相同的形式上转换(采用一次一比特的方式),这有助于多个下层子层(PMD)对不同媒介的支持.另外,PMA也具有时钟恢复和媒介冲突检测的功能。

    (4)PMD
    从PMA读取数据并且执行电路信号转换。
    或者是读取电路信号,将其转化为比特流传入PMA子层。

    (5)MDI
    通常为控制器和线缆之间的接口。

    数据链路层

    以太网数据帧格式

    以太网链路传输的数据包称做以太帧,或者以太网数据帧。在以太网中,网络访问层的软件必须把数据转换成能够通过网络适配器硬件进行传输的格式。

    以太帧的工作机制

    当以太网软件从网络层接收到数据报之后,需要完成如下操作:
    1) 根据需要把网络层的数据分解为较小的块,以符合以太网帧数据段的要求。以太网帧的整体大小必须在 64~1518 字节之间(不包含前导码)。有些系统支持更大的帧,最大可以支持 9000 字节。
    2) 把数据块打包成帧。每一帧都包含数据及其他信息,这些信息是以太网网络适配器处理帧所需要的。
    3) 把数据帧传递给对应于 OSI 模型物理层的底层组件,后者把帧转换为比特流,并且通过传输介质发送出去。
    4) 以太网上的其他网络适配器接收到这个帧,检查其中的目的地址。如果目的地址与网络适配器的地址相匹配,适配器软件就会处理接收到的帧,把数据传递给协议栈中较高的层。

    以太帧的结构

    以太帧起始部分由前同步码和帧开始定界符组成,后面紧跟着一个以太网报头,以 MAC 地址说明目的地址和源地址。以太帧的中部是该帧负载的包含其他协议报头的数据包,如 IP 协议。
    以太帧由一个 32 位冗余校验码结尾,用于检验数据传输是否出现损坏。以太帧结构如图所示。
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mdka5iMH-1644201046739)(media/image3.GIF)]{width="5.147916666666666in" height="2.2930555555555556in"}
    上图中每个字段的含义如下表所示:

    1. 前同步码:用来使接收端的适配器在接收 MAC 帧时能够迅速调整时钟频率,使它和发送端的频率相同。前同步码为 7 个字节,1 和 0 交替。
    2. 帧开始定界符:帧的起始符,为 1 个字节。前 6 位 1 和 0 交替,最后的两个连续的 1 表示告诉接收端适配器:“帧信息要来了,准备接收”。
    3. 目的地址:接收帧的网络适配器的物理地址(MAC 地址),为 6 个字节(48 比特)。作用是当网卡接收到一个数据帧时,首先会检查该帧的目的地址,是否与当前适配器的物理地址相同,如果相同,就会进一步处理;如果不同,则直接丢弃。
    4. 源地址:发送帧的网络适配器的物理地址(MAC 地址),为 6 个字节(48 比特)。
    5. 类型:上层协议的类型。由于上层协议众多,所以在处理数据的时候必须设置该字段,标识数据交付哪个协议处理。例如,字段为 0x0800 时,表示将数据交付给 IP 协议。
    6. 数据:也称为效载荷,表示交付给上层的数据。以太网帧数据长度最小为 46 字节,最大为 1500 字节。如果不足 46 字节时,会填充到最小长度。最大值也叫最大传输单元(MTU)。

    在 Linux 中,使用 ifconfig 命令可以查看该值,通常为 1500。

    帧检验序列 FCS 检测该帧是否出现差错,占 4 个字节(32 比特)。发送方计算帧的循环冗余码校验(CRC)值,把这个值写到帧里。接收方计算机重新计算 CRC,与 FCS 字段的值进行比较。如果两个值不相同,则表示传输过程中发生了数据丢失或改变。这时,就需要重新传输这一帧。

    以太帧报文格式

    在这里插入图片描述

    ARP协议寻址

    ARP协议的工作机制

    ARP 是"Address Resolution Protocol"的缩写,译为"地址解析协议",它是根据 IP 地址获取物理地址的一个 TCP/IP 协议。
    ARP 协议通过 IP 地址向 MAC 地址的转换,解决网际层和网络访问层的衔接问题。
    由于 IP 地址和 MAC 地址定位方式不同,ARP 协议成为数据传输的必备协议。主机发送信息前,必须通过 ARP 协议获取目标 IP 地址对应的 MAC 地址,才能正确地发送数据包。

    (1) 为什么需要 ARP 协议
    在网络访问层中,同一局域网中的一台主机要和另一台主机进行通信,需要通过 MAC 地址进行定位,然后才能进行数据包的发送。
    而在网络层和传输层中,计算机之间是通过 IP 地址定位目标主机,对应的数据报文只包含目标主机的 IP 地址,而没有 MAC 地址。
    因此,在发送之前需要根据 IP 地址获取 MAC 地址,然后才能将数据包发送到正确的目标主机,而这个获取过程是通过 ARP 协议完成的。

    (2) ARP 工作的基本流程
    ARP 工作流程分为两个阶段,一个是 ARP 请求过程,另一个是 ARP 响应过程。

    工作流程如下所示。
    在这里插入图片描述

    在上面图片中,主机 A 的 IP 地址为 192.168.1.1,主机 B 的 IP 地址为 192.168.1.2。

    主机 A 与主机 B 进行通信,需要获取其 MAC 地址,基本流程如下:

    主机 A 以广播形式向网络中所有主机发送 ARP 请求,请求包中包含了目标 IP 地址 192.168.1.2。

    主机 B 接收到请求,发现自己就是主机 A 要找的主机,返回响应,响应包中包含自己的 MAC 地址。

    (3) ARP 缓存

    在请求目标主机的 MAC 地址时,每次获取目标主机 MAC 地址都需要发送一次 ARP 请求,然后根据响应获取到 MAC 地址。

    为了避免重复发送 ARP 请求,每台主机都有一个 ARP 高速缓存。当主机得到 ARP 响应后,将目标主机的 IP 地址和物理地址存入本机 ARP 缓存中,并保留一定时间。

    只要在这个时间范围内,下次请求 MAC 地址时,直接查询 ARP 缓存,而无须再发送 ARP 请求,从而节约了网络资源。

    当有了 ARP 缓存以后,ARP 的工作流程如下:
    1) 主机 A 在本机 ARP 缓存中检查主机 B 的匹配 MAC 地址。
    2) 如果在 ARP 缓存中没有找到主机 B 的 IP 地址及对应的 MAC 地址,它将询问主机 B 的 MAC 地址,从而将 ARP 请求帧广播到本地网络上的所有主机。源主机 A 的 IP 地址和 MAC 地址都包括在 ARP 请求中。
    3) 本地网络上的每台主机都接收到 ARP 请求,并且检查是否与自己的 IP 地址匹配。如果主机发现请求的 IP 地址与自己的 IP 地址不匹配,它将丢弃 ARP 请求。主机 B 确定 ARP 请求中的 IP 地址与自己的 IP 地址匹配,则将主机 A 的 IP 地址和 MAC 地址映射添加到本地 ARP 缓存中。
    4) 主机 B 将包含自身 MAC 地址的 ARP 回复消息直接发送给主机 A。
    5) 当主机 A 收到从主机 B 发来的 ARP 回复消息时,会用主机 B 的 IP 地址和 MAC 地址更新 ARP 缓存。
    6) 主机 B 的 MAC 地址一旦确定,主机 A 就能向主机 B 发送 IP 数据包。本机缓存是有生存期的,生存期结束后,将再次重复上面的过程。

    (4) 查看 ARP 缓存

    每次成功得到 ARP 响应以后,就会将 IP 地址对应的 MAC 地址添加到 ARP 缓存中。用户可以通过 arp 命令查看 ARP 缓存中的信息,并验证是否会将目标 IP 地址和 MAC 地址添加到 ARP 缓存中。

    【示例】查看 ARP 缓存表并验证添加的 IP 地址和 MAC 地址。
    1) 使用 arp 命令查看当前主机缓存信息,执行命令如下:
    root@daxueba:~# arp -a

    输出信息如下:
    localhost (192.168.59.254) at 00:50:56:f7:9b:0d [ether] on eth0
    localhost (192.168.59.2) at 00:50:56:ea:f3:a1 [ether] on eth0

    上述输出信息表示当前 ARP 缓存中有两组信息,192.168.59.254 对应的 MAC 地址为 00:50:56:f7:9b:0d,192.168.59.2 对应的 MAC 地址为 00:50:56:ea:f3:a1。

    2) 在当前主机上与主机 192.168.59.135 进行通信。例如,可以使用 ping 命令探测该主机。执行命令如下:
    root@daxueba:~# ping 192.168.59.135

    输出信息如下:
    PING 192.168.59.135 (192.168.59.135) 56(84) bytes of data.
    64 bytes from 192.168.59.135: icmp_seq=1 ttl=64 time=1.64 ms
    64 bytes from 192.168.59.135: icmp_seq=2 ttl=64 time=0.420 ms
    64 bytes from 192.168.59.135: icmp_seq=3 ttl=64 time=0.405 ms
    64 bytes from 192.168.59.135: icmp_seq=4 ttl=64 time=0.343 ms

    上述输出信息表示成功向目标主机 192.168.59.135 发送了 ping 请求并得到了响应。

    3) 当前主机的 ARP 缓存将会添加目标主机的 IP 地址及 MAC 地址。再次查看当前主机缓存信息,执行命令如下:
    root@daxueba:~# arp -a
    localhost (192.168.59.135) at 00:0c:29:ca:e4:66 [ether] on eth0
    localhost (192.168.59.254) at 00:50:56:f7:9b:0d [ether] on eth0
    localhost (192.168.59.2) at 00:50:56:ea:f3:a1 [ether] on eth0

    上述输出信息中加粗部分为添加到 ARP 缓存中的目标主机的 IP 地址和 MAC 地址信息。

    ARP 报文格式

    ARP 协议是通过报文进行工作的,ARP 报文格式如图所示。
    在这里插入图片描述

    ARP 报文总长度为 28 字节,MAC 地址长度为 6 字节,IP 地址长度为 4 字节。不够以太网传输最短字节60,剩余的用00填充。

    其中,每个字段的含义如下。

    1. 硬件类型:指明了发送方想知道的硬件接口类型,以太网的值为 1。
    2. 协议类型:表示要映射的协议地址类型。它的值为 0x0800,表示 IP 地址。
    3. 硬件地址长度和协议长度:分别指出硬件地址和协议的长度,以字节为单位。对于以太网上 IP 地址的ARP请求或应答来说,它们的值分别为 6 和 4。
    4. 操作类型:用来表示这个报文的类型,ARP 请求为 1,ARP 响应为 2,RARP 请求为 3,RARP 响应为 4。
    5. 发送方 MAC 地址:发送方设备的硬件地址。
    6. 发送方 IP 地址:发送方设备的 IP 地址。
    7. 目标 MAC 地址:接收方设备的硬件地址。
    8. 目标 IP 地址:接收方设备的IP地址。

    ARP 数据包分为请求包和响应包,对应报文中的某些字段值也有所不同。

    ARP 请求包报文的操作类型(op)字段的值为 request(1),目标 MAC 地址字段的值为 Target 00:00:00_00:00:00(00:00:00:00:00:00)(广播地址)。

    ARP 响应包报文中操作类型(op)字段的值为 reply(2),目标 MAC 地址字段的值为目标主机的硬件地址。

    在这里插入图片描述

    PPP协议的帧格式

    Cainv89 2016-02-04 11:53:30 45058 收藏 40

    PPP帧各字段的意义

    PPP帧的首部和尾部分别为四个字段和两个字段。
    在这里插入图片描述
    (1) PPP帧的首部

    首部中的标志字段F(Flag),规定为0x7E(符号0x表示它后面的字符是用十六进制表示的。十六进制的7E的二进制表示是01111110),标志字段表示一个帧的开始。
    首部中的地址字段A规定为0xFF(即11111111)。
    首部中的控制字段C规定为0x03(即00000011)。

    首部中的2字节的协议字段:
    (1)当协议字段为0x0021时,PPP帧的信息字段就是IP数据报。
    (2)当协议字段为0xC021时,PPP帧的信息字段就是PPP链路控制协议LCP的数据。
    (3)当协议字段为0x8021时,PPP帧的信息字段就是网络层的控制数据。

    (2) PPP帧的信息字段部分
    信息字段的长度是可变的,不超过1500字节。

    (3) PPP帧的尾部

    尾部中的第一个字段(2个字节)是使用CRC的帧检验序列FCS。
    尾部中的标志字段F(Flag),规定为0x7E(符号0x表示它后面的字符是用十六进制表示的。十六进制的7E的二进制表示是01111110),标志字段表示一个帧的结束。

    注:标志字段就是PPP帧的定界符。连续两帧之间只需要用一个标志字段。如果连续出现两个标志字段,就表示这是一个空帧,应当丢弃。

    透明传输的实现方式

    当信息字段中出现和标志字段一样的比特(0x7E)组合时,就必须采取一些措施使这种形式上和标志字段一言的比特组合不出现在信息字段中。

    (1) 字节填充------PPP使用异步传输

    当PPP使用异步传输时,它把转移符定义为0x7D,并使用字节填充。

    RFC1662规定了如下填充方法:
    (1)把信息字段中出现的每一个0x7E字节转变为2字节序列(0x7D,0x5E)。
    (2)若信息字段中出现一个0x7D的字节(即出现了和转义字符一样的比特组合),则把转义字符0x7D转变为2字节序列(0x7D,0x5D)。
    (3)若信息字段中出现ASCII码的控制字符(即数值小于0x20的字符),则在该字符前面要加入一个0x7D字节,同时将该字符的编码加以改变。例如,出现0x03(在控制字符中是"传输结束"ETX)就要把它转变为2字节序列的(0x7D,0x31)。

    由于在发送端进行了字节填充,因此在链路上传送的信息字节数就超过了原来的信息字节数。但接收端在接收到数据后再进行与发送端字节填充相反的变换,就可以正确地恢复出原来的信息。

    (2) 零比特填充------PPP使用同步传输

    当PPP使用同步传输时,使用零比特填充。

    零比特填充的具体方法:
    (1)在发送端先扫描整个信息字段(通常使用硬件实现,但也可以用软件实现,但是会慢一些)。
    (2)只要发现有5个连续的1,则立即填入一个0。
    (3)接收端在收到一个帧时,先找到标志字段F以确定帧的边界,接着再用硬件对其中的比特流进行扫描,每当发现5个连续1时,就把5个连续1后的一个0删除,以还原成原来的信息比特流。

    因此通过这种零比特填充后的数据,就可以保证在信息字段中不会出现连续6个1。
    在这里插入图片描述

    网络层

    IP协议

    IP协议的工作机制

    IP 协议提供了一种分层的、与硬件无关的寻址系统,它可以在复杂的路由式网络中传递数据所需的服务。
    IP 协议可以将多个交换网络连接起来,在源地址和目的地址之间传送数据包。同时,它还提供数据重新组装功能,以适应不同网络对数据包大小的要求。
    在一个路由式网络中,源地址主机向目标地址主机发送数据时,IP协议是如何将数据成功发送到目标主机上的呢?由于网络分同网段和不同网段两种情况,工作方式如下:

    1. 同网段:如果源地址主机和目标地址主机在同一网段,目标 IP 地址被 ARP 协议解析为 MAC 地址,然后根据 MAC 地址,源主机直接把数据包发给目标主机。
    2. 不同网段:如果源地址主机和目标地址主机在不同网段,数据包发送过程如下:
      网关(一般为路由器)的 IP 地址被 ARP 协议解析为 MAC 地址。根据该 MAC 地址,源主机将数据包发送到网关。网关根据数据包中的网段 ID 寻找目标网络。如果找到,将数据包发送到目标网段;如果没找到,重复步骤(1)将数据包发送到上一级网关。数据包经过网关被发送到正确的网段中。目标IP地址被ARP协议解析为 MAC 地址。根据该 MAC 地址,数据包被发送给目标地址的主机。

    IP数据报格式详解

    在 TCP/IP 协议中,使用 IP 协议传输数据的包被称为 IP 数据包,每个数据包都包含 IP 协议规定的内容。IP 协议规定的这些内容被称为 IP 数据报文(IP Datagram)或者 IP 数据报。
    IP 数据报文由首部(称为报头)和数据两部分组成。首部的前一部分是固定长度,共 20 字节,是所有 IP 数据报必须具有的。在首部的固定部分的后面是一些可选字段,其长度是可变的。
    每个 IP 数据报都以一个 IP 报头开始。源计算机构造这个 IP 报头,而目的计算机利用 IP 报头中封装的信息处理数据。IP 报头中包含大量的信息,如源 IP 地址、目的 IP 地址、数据报长度、IP 版本号等。每个信息都被称为一个字段。

    IP 数据报头字段如图所示。
    在这里插入图片描述

    IP 报头的最小长度为 20 字节,上图中每个字段的含义如下:

    1. 版本(version):占 4 位,表示 IP 协议的版本。通信双方使用的 IP 协议版本必须一致。目前广泛使用的IP协议版本号为 4,即 IPv4。
    2. 首部长度(网际报头长度IHL):占 4 位,可表示的最大十进制数值是 15。这个字段所表示数的单位是 32 位字长(1 个 32 位字长是 4 字节)。因此,当 IP 的首部长度为 1111 时(即十进制的 15),首部长度就达到 60 字节。当 IP 分组的首部长度不是 4 字节的整数倍时,必须利用最后的填充字段加以填充。数据部分永远在 4 字节的整数倍开始,这样在实现 IP 协议时较为方便。首部长度限制为 60 字节的缺点是,长度有时可能不够用,之所以限制长度为 60 字节,是希望用户尽量减少开销。最常用的首部长度就是 20 字节(即首部长度为 0101),这时不使用任何选项。
    3. 区分服务(tos):也被称为服务类型,占 8 位,用来获得更好的服务。这个字段在旧标准中叫做服务类型,但实际上一直没有被使用过。1998 年 IETF 把这个字段改名为区分服务(Differentiated Services,DS)。只有在使用区分服务时,这个字段才起作用。
    4. 总长度(totlen):首部和数据之和,单位为字节。总长度字段为 16 位,因此数据报的最大长度为 2^16-1=65535 字节。
    5. 标识(identification):用来标识数据报,占 16 位。IP 协议在存储器中维持一个计数器。每产生一个数据报,计数器就加 1,并将此值赋给标识字段。当数据报的长度超过网络的 MTU,而必须分片时,这个标识字段的值就被复制到所有的数据报的标识字段中。具有相同的标识字段值的分片报文会被重组成原来的数据报。
    6. 标志(flag):占 3 位。第一位未使用,其值为 0。第二位称为 DF(不分片),表示是否允许分片。取值为 0 时,表示允许分片;取值为 1 时,表示不允许分片。第三位称为 MF(更多分片),表示是否还有分片正在传输,设置为 0 时,表示没有更多分片需要发送,或数据报没有分片。
    7. 片偏移(offsetfrag):占 13 位。当报文被分片后,该字段标记该分片在原报文中的相对位置。片偏移以 8 个字节为偏移单位。所以,除了最后一个分片,其他分片的偏移值都是 8 字节(64 位)的整数倍。
    8. 生存时间(TTL):表示数据报在网络中的寿命,占 8 位。该字段由发出数据报的源主机设置。其目的是防止无法交付的数据报无限制地在网络中传输,从而消耗网络资源。路由器在转发数据报之前,先把 TTL 值减 1。若 TTL 值减少到 0,则丢弃这个数据报,不再转发。因此,TTL 指明数据报在网络中最多可经过多少个路由器。TTL 的最大数值为 255。若把 TTL 的初始值设为 1,则表示这个数据报只能在本局域网中传送。
    9. 协议:表示该数据报文所携带的数据所使用的协议类型,占 8 位。该字段可以方便目的主机的 IP 层知道按照什么协议来处理数据部分。不同的协议有专门不同的协议号。例如,TCP 的协议号为 6,UDP 的协议号为 17,ICMP 的协议号为 1。
    10. 首部检验和(checksum):用于校验数据报的首部,占 16 位。数据报每经过一个路由器,首部的字段都可能发生变化(如TTL),所以需要重新校验。而数据部分不发生变化,所以不用重新生成校验值。
    11. 源地址:表示数据报的源 IP 地址,占 32 位。
    12. 目的地址:表示数据报的目的 IP 地址,占 32 位。该字段用于校验发送是否正确。
    13. 可选字段:该字段用于一些可选的报头设置,主要用于测试、调试和安全的目的。这些选项包括严格源路由(数据报必须经过指定的路由)、网际时间戳(经过每个路由器时的时间戳记录)和安全限制。
    14. 填充:由于可选字段中的长度不是固定的,使用若干个 0 填充该字段,可以保证整个报头的长度是 32 位的整数倍。
    15. 数据部分:表示传输层的数据,如保存 TCP、UDP、ICMP 或 IGMP 的数据。数据部分的长度不固定。

    IP报文实例在这里插入图片描述

    传输层

    ICMP协议

    控制报文协议(Internet Control Message Protocol,ICMP)是 TCP/IP 协议族的一个子协议。ICMP 协议用于在 IP 主机和路由器之间传递控制消息,描述网络是否通畅、主机是否可达、路由器是否可用等网络状态。
    由于 IP 协议简单,数据传输天然存在不可靠、无连接等特点,为了解决数据传输出现的问题,人们引入了 ICMP 协议。虽然 ICMP 协议的数据包并不传输用户数据,但是对于用户数据的传递起着重要的作用。

    ICMP 协议作用

    数据包在发送到目标主机的过程中,通常会经过一个或多个路由器。而数据包在通过这些路由进行传输时,可能会遇到各种问题,导致数据包无法发送到目标主机上。为了了解数据包在传输的过程中在哪个环节出现了问题,就需要用到 ICMP 协议。它可以跟踪消息,把问题反馈给源主机。

    ICMP 报文结构

    ICMP 报文一般为 8 个字节,包括类型、代码、校验和扩展内容字段。ICMP 报文基本结构如图所示。
    在这里插入图片描述
    其中,类型表示 ICMP 的消息类型,代码表示对类型的进一步说明,校验和表示对整个报文的报文信息的校验。
    在 ICMP 报文中,如果类型和代码不同,ICMP 数据包报告的消息含义也会不同。常见的类型和代码的 ICMP 含义如表所示。

    ICMP 类型、代码及含义
    类型 代码 含义
    0 0 回显应答(ping 应答)
    3 0 网络不可达
    3 1 主机不可达
    3 2 协议不可达
    3 3 端口不可达
    3 4 需要进行分片,但设置不分片位
    3 5 源站选路失败
    3 6 目的网络未知
    3 7 目的主机未知
    3 9 目的网络被强制禁止
    3 10 目的主机被强制禁止
    3 11 由于服务类型 TOS,网络不可达
    3 12 由于服务类型 TOS,主机不可达
    3 13 由于过滤,通信被强制禁止
    3 14 主机越权
    3 15 优先中止失效
    4 0 源端被关闭(基本流控制)
    5 0 对网络重定向
    5 1 对主机重定向
    5 2 对服务类型和网络重定向
    5 3 对服务类型和主机重定向
    8 0 回显请求(ping 请求)
    9 0 路由器通告
    10 0 路由器请求
    11 0 传输期间生存时间为 0
    11 1 在数据报组装期间生存时间为 0
    12 0 坏的 IP 首部
    12 1 缺少必需的选项
    13 0 时间戳请求
    14 0 时间戳应答
    17 0 地址掩码请求
    18 0 地址掩码应答

    ICMP报文实例

    在这里插入图片描述

    TCP协议

    TCP协议的工作机制

    传输控制协议(Transmission Control Protocol,TCP)是一种面向连接的、可靠的、基于字节流的传输层通信协议。在 TCP 协议中,通过三次握手建立连接。通信结束后,还需要断开连接。如果在发送数据包时,没有正确被发送到目的地时,将会重新发送数据包。

    TCP 协议使用的是面向连接的方法进行通信的,其作用如下:

    1. 面向流的处理:TCP 以流的方式处理数据。换句话说,TCP 可以一个字节一个字节地接收数据,而不是一次接收一个预订格式的数据块。TCP 把接收到的数据组成长度不等的段,再传递到网际层。
    2. 重新排序:如果数据以错误的顺序到达目的地,TCP 模块能够对数据重新排序,来恢复原始数据。
    3. 流量控制:TCP 能够确保数据传输不会超过目的计算机接收数据的能力。
    4. 优先级与安全:为 TCP 连接设置可选的优先级和安全级别。
    5. 适当的关闭:以确保所有的数据被发送或接收以后,再进行关闭连接。

    TCP 协议的数据包进行传输采用的是服务器端和客户端模式。发送 TCP 数据请求方为客户端,另一方则为服务器端。客户端要与服务器端进行通信,服务器端必须开启监听的端口,客户端才能通过端口连接到服务器,然后进行通信。

    TCP报文格式解析

    TCP 报文是 TCP 层传输的数据单元,也称为报文段。TCP 报文中每个字段如图所示。
    在这里插入图片描述
    上图中 TCP 报文中每个字段的含义如下:

    1. 源端口和目的端口字段:TCP源端口(Source Port):源计算机上的应用程序的端口号,占 16 位。TCP目的端口(Destination Port):目标计算机的应用程序端口号,占 16 位。
    2. 序列号字段:CP序列号(Sequence Number):占 32 位。它表示本报文段所发送数据的第一个字节的编号。在 TCP 连接中,所传送的字节流的每一个字节都会按顺序编号。当SYN标记不为1时,这是当前数据分段第一个字母的序列号;如果SYN的值是1时,这个字段的值就是初始序列值(ISN),用于对序列号进行同步。这时,第一个字节的序列号比这个字段的值大1,也就是ISN加1。
    3. 确认号字段:TCP 确认号(Acknowledgment Number,ACK Number):占 32 位。它表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。其值是接收计算机即将接收到的下一个序列号,也就是下一个接收到的字节的序列号加1。
    4. 数据偏移字段:TCP 首部长度(Header Length):数据偏移是指数据段中的"数据"部分起始处距离 TCP 数据段起始处的字节偏移量,占 4 位。其实这里的"数据偏移"也是在确定 TCP 数据段头部分的长度,告诉接收端的应用程序,数据从何处开始。
    5. 保留字段:保留(Reserved):占 4 位。为 TCP 将来的发展预留空间,目前必须全部为 0。
    6. 标志位字段:
      1.CWR(Congestion Window Reduce):拥塞窗口减少标志,用来表明它接收到了设置 ECE 标志的 TCP 包。并且,发送方收到消息之后,通过减小发送窗口的大小来降低发送速率。
      2.ECE(ECN Echo):用来在 TCP 三次握手时表明一个 TCP 端是具备 ECN 功能的。在数据传输过程中,它也用来表明接收到的 TCP 包的 IP 头部的 ECN 被设置为 11,即网络线路拥堵。
      3.URG(Urgent):表示本报文段中发送的数据是否包含紧急数据。URG=1 时表示有紧急数据。当 URG=1 时,后面的紧急指针字段才有效。
      4.ACK:表示前面的确认号字段是否有效。ACK=1 时表示有效。只有当 ACK=1 时,前面的确认号字段才有效。TCP 规定,连接建立后,ACK 必须为 1。
      5.PSH(Push):告诉对方收到该报文段后是否立即把数据推送给上层。如果值为 1,表示应当立即把数据提交给上层,而不是缓存起来。
      6.RST:表示是否重置连接。如果 RST=1,说明 TCP 连接出现了严重错误(如主机崩溃),必须释放连接,然后再重新建立连接。
      7.SYN:在建立连接时使用,用来同步序号。当 SYN=1,ACK=0 时,表示这是一个请求建立连接的报文段;当 SYN=1,ACK=1 时,表示对方同意建立连接。SYN=1 时,说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中 SYN 才为 1。
      8.FIN:标记数据是否发送完毕。如果 FIN=1,表示数据已经发送完成,可以释放连接。
    7. 窗口大小字段:窗口大小(Window Size):占 16 位。它表示从 Ack Number 开始还可以接收多少字节的数据量,也表示当前接收端的接收窗口还有多少剩余空间。该字段可以用于 TCP 的流量控制。
    8. TCP 校验和字段:校验位(TCP Checksum):占 16 位。它用于确认传输的数据是否有损坏。发送端基于数据内容校验生成一个数值,接收端根据接收的数据校验生成一个值。两个值必须相同,才能证明数据是有效的。如果两个值不同,则丢掉这个数据包。Checksum 是根据伪头 + TCP 头 + TCP 数据三部分进行计算的。
    9. 紧急指针字段:紧急指针(Urgent Pointer):仅当前面的 URG 控制位为 1 时才有意义。它指出本数据段中为紧急数据的字节数,占 16 位。当所有紧急数据处理完后,TCP 就会告诉应用程序恢复到正常操作。即使当前窗口大小为 0,也是可以发送紧急数据的,因为紧急数据无须缓存。
    10. 可选项字段:选项(Option):长度不定,但长度必须是 32bits 的整数倍。

    TCP报文实例

    在这里插入图片描述

    UDP协议

    UDP协议简介

    用户数据报协议(User Datagram Protocol,UDP)是一种传输层协议。在 TCP/IP 网络中,它与 TCP 协议一样用于处理数据包,是一种无连接的协议。
    TCP 协议在进行数据传输时,需要建立连接,并且每次传输的数据都需要进行确认。当不再进行传输数据时,还需要断开连接。这样做虽然安全,但是效率较低。而 UDP 协议正好避免了这些过程,它是一种没有复杂控制,提供面向无连接的通信服务协议。

    UDP 协议具备以下特点:

    1. 没有各种连接:在传输数据前不需要建立连接,也避免了后续的断开连接。
    2. 不重新排序:对到达顺序混乱的数据包不进行重新排序。
    3. 没有确认:发送数据包无须等待对方确认。因此,使用 UDP 协议可以随时发送数据,但无法保证数据能否成功被目标主机接收。

    UDP报文格式详解

    相比 TCP 协议,UDP 协议的报文结构相对简单。
    每个 UDP 报文分为 UDP 报头和 UDP 数据区两部分。报头由 4 个 16 位长(2 字节)字段组成,分别说明该报文的源端口、目的端口、报文长度和校验值。

    UDP 报文格式如图所示。
    在这里插入图片描述
    UDP 报文中每个字段的含义如下:

    1. 源端口:这个字段占据 UDP 报文头的前 16 位,通常包含发送数据报的应用程序所使用的 UDP 端口。接收端的应用程序利用这个字段的值作为发送响应的目的地址。这个字段是可选的,所以发送端的应用程序不一定会把自己的端口号写入该字段中。如果不写入端口号,则把这个字段设置为 0。这样,接收端的应用程序就不能发送响应了。
    2. 目的端口:接收端计算机上 UDP 软件使用的端口,占据 16 位。
    3. 长度:该字段占据 16 位,表示 UDP 数据报长度,包含 UDP 报文头和 UDP 数据长度。因为 UDP 报文头长度是 8 个字节,所以这个值最小为 8。
    4. 校验值:该字段占据 16 位,可以检验数据在传输过程中是否被损坏。

    UDP报文实例

    在这里插入图片描述

    应用层

    HTTP协议

    博客园 ranyonsue

    HTTP之URL

    HTTP使用统一资源标识符(Uniform Resource Identifiers, URI)来传输数据和建立连接。URL是一种特殊类型的URI,包含了用于查找某个资源的足够的信息
    URL,全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例,介绍下普通URL的各部分组成:
    http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

    从上面的URL可以看出,一个完整的URL包括以下几部分:
    (1) 协议部分:该URL的协议部分为"http:",这代表网页使用的是HTTP协议。在Internet中可以使用多种协议,如HTTP,FTP等等本例中使用的是HTTP协议。在"HTTP"后面的"//“为分隔符。
    (2) **域名部分:**该URL的域名部分为"www.aspxfans.com”。一个URL中,也可以使用IP地址作为域名使用。
    (3) 端口部分:跟在域名后面的是端口,域名和端口之间使用":“作为分隔符。端口不是一个URL必须的部分,如果省略端口部分,将采用默认端口。
    (4) 虚拟目录部分:从域名后的第一个”/“开始到最后一个”/“为止,是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是”/news/"。
    (5) 文件名部分:从域名后的最后一个"/“开始到”?“为止,是文件名部分,如果没有”?",则是从域名后的最后一个"/“开始到”#“为止,是文件部分,如果没有”?“和”#",那么从域名后的最后一个"/“开始到结束,都是文件名部分。本例中的文件名是"index.asp”。文件名部分也不是一个URL必须的部分,如果省略该部分,则使用默认的文件名。
    (6) 参数部分:从"?“开始到”#“为止之间的部分为参数部分,又称搜索部分、查询部分。本例中的参数部分为"boardID=5&ID=24618&page=1”。参数可以允许有多个参数,参数与参数之间用"&“作为分隔符。
    (7) 锚部分:从”#“开始到最后,都是锚部分。本例中的锚部分是"name”。锚部分也不是一个URL必须的部分。

    (原文:http://blog.csdn.net/ergouge/article/details/8185219 )

    HTTP之请求消息Request

    客户端发送一个HTTP请求到服务器的请求消息包括以下格式:
    请求行(request line)、请求头部(header)、空行和请求数据四个部分组成。
    在这里插入图片描述
    请求行以一个方法符号开头,以空格分开,后面跟着请求的URI和协议的版本。
    (1) Get请求例子,使用Charles抓取的request:
    GET /562f25980001b1b106000338.jpg HTTP/1.1
    Host img.mukewang.com
    User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
    Accept image/webp,image/*,*/*;q=0.8
    Referer http://www.imooc.com/
    Accept-Encoding gzip, deflate, sdch
    Accept-Language zh-CN,zh;q=0.8

    第一部分:请求行,用来说明请求类型,要访问的资源以及所使用的HTTP版本.
    GET说明请求类型为GET,[/562f25980001b1b106000338.jpg]为要访问的资源,该行的最后一部分说明使用的是HTTP1.1版本。

    第二部分:请求头部,紧接着请求行(即第一行)之后的部分,用来说明服务器要使用的附加信息
    从第二行起为请求头部,HOST将指出请求的目的地.User-Agent,服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送等等

    第三部分:空行,请求头部后面的空行是必须的
    即使第四部分的请求数据为空,也必须有空行。

    第四部分:请求数据也叫主体,可以添加任意的其他数据。
    这个例子的请求数据为空。

    (2) POST请求例子,使用Charles抓取的request:
    POST / HTTP1.1
    Host:www.wrox.com
    User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
    Content-Type:application/x-www-form-urlencoded
    Content-Length:40
    Connection: Keep-Alive
    name=Professional%20Ajax&publisher=Wiley

    第一部分:请求行,第一行明了是post请求,以及http1.1版本。

    第二部分:请求头部,第二行至第六行。

    第三部分:空行,第七行的空行。

    第四部分:请求数据,第八行。

    HTTP之响应消息Response

    一般情况下,服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息。

    HTTP响应也由四个部分组成,分别是:状态行、消息报头、空行和响应正文。
    在这里插入图片描述
    在这里插入图片描述

    第一部分:状态行,由HTTP协议版本号, 状态码, 状态消息 三部分组成。

    第一行为状态行,(HTTP/1.1)表明HTTP版本为1.1版本,状态码为200,状态消息为(ok)

    第二部分:消息报头,用来说明客户端要使用的一些附加信息

    第二行和第三行为消息报头,Date:生成响应的日期和时间;Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8

    第三部分:空行,消息报头后面的空行是必须的

    第四部分:响应正文,服务器返回给客户端的文本信息。

    空行后面的html部分为响应正文。

    HTTP之状态码

    状态代码有三位数字组成,第一个数字定义了响应的类别,共分五种类别:

    1xx:指示信息–表示请求已接收,继续处理

    2xx:成功–表示请求已被成功接收、理解、接受

    3xx:重定向–要完成请求必须进行更进一步的操作

    4xx:客户端错误–请求有语法错误或请求无法实现

    5xx:服务器端错误–服务器未能实现合法的请求

    常见状态码:

    200 OK //客户端请求成功

    400 Bad Request //客户端请求有语法错误,不能被服务器所理解

    401 Unauthorized //请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用

    403 Forbidden //服务器收到请求,但是拒绝提供服务

    404 Not Found //请求资源不存在,eg:输入了错误的URL

    500 Internal Server Error //服务器发生不可预期的错误

    503 Server Unavailable //服务器当前不能处理客户端的请求,一段时间后可能恢复正常

    更多状态码http://www.runoob.com/http/http-status-codes.html

    HTTP请求方法

    根据HTTP标准,HTTP请求可以使用多种请求方法。

    HTTP1.0定义了三种请求方法: GET, POST 和 HEAD方法。

    HTTP1.1新增了五种请求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

    GET 请求指定的页面信息,并返回实体主体。

    HEAD 类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头

    POST 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。

    PUT 从客户端向服务器传送的数据取代指定的文档的内容。

    DELETE 请求服务器删除指定的页面。

    CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

    OPTIONS 允许客户端查看服务器的性能。

    TRACE 回显服务器收到的请求,主要用于测试或诊断。

    HTTP工作原理

    HTTP协议定义Web客户端如何从Web服务器请求Web页面,以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文,请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应,响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

    以下是 HTTP 请求/响应的步骤:

    1、客户端连接到Web服务器
    一个HTTP客户端,通常是浏览器,与Web服务器的HTTP端口(默认为80)建立一个TCP套接字连接。例如,http://www.oakcms.cn。

    2、发送HTTP请求
    通过TCP套接字,客户端向Web服务器发送一个文本的请求报文,一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

    3、服务器接受请求并返回HTTP响应
    Web服务器解析请求,定位请求资源。服务器将资源复本写到TCP套接字,由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

    4、释放连接TCP连接
    若connection 模式为close,则服务器主动关闭TCP连接,客户端被动关闭连接,释放TCP连接;若connection 模式为keepalive,则该连接会保持一段时间,在该时间内可以继续接收请求;

    5、客户端浏览器解析HTML内容
    客户端浏览器首先解析状态行,查看表明请求是否成功的状态代码。然后解析每一个响应头,响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML,根据HTML的语法对其进行格式化,并在浏览器窗口中显示。

    例如:在浏览器地址栏键入URL,按下回车之后会经历以下流程:
    1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
    2、解析出 IP 地址后,根据该 IP 地址和默认端口 80,和服务器建立TCP连接;
    3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求,该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
    4、服务器对浏览器请求作出响应,并把对应的 html 文本发送给浏览器;
    5、释放 TCP连接;
    6、浏览器将该 html 文本并显示内容;

    FTP协议

    iteye_5722 2016-11-13 14:28:46 713 收藏 7

    简介

    FTP的传输使用的是TCP数据包协议,TCP在建立连接前会先进行三次握手。不过FTP服务器比较麻烦一些,因为FTP服务器使用了两个连接,分别是命令通道与数据通道。因为是TCP数据包,所以这两个连接都需要经过三次握手。
    根据数据连接的建立方式,FTP服务的数据传输可以分为主动模式(Active)和被动(Passive)模式。下面就这两种模式分别进行介绍。

    主动模式

    1、定义
    主动模式是FTP服务器向FTP客户端传输数据的默认模式。当FTP客户端请求以主动模式传输数据时,由客户端向服务器端发送准备接受数据的IP地址和端口Y,该端口应该是大于1024的非特权端口。服务器端主动发起并建立到指定的IP地址和端口Y上的连接。由于Y端可以随机指定,导致这种方案要求客户端机器必须允许FTP服务器能够顺利地连接所有的端口,因此可能存在一定的安全隐患。

    2、FTP服务器主动连接示意图
    在这里插入图片描述

    3、主动模式分析

    步骤一:建立命令通道连接
    如上图,客户端会随机取一个大于1024以上的端口(port AA)来与FTP服务器端的port 21实现连接,这个过程当然需要三次握手。实现连接后客户端便可以通过这个连接来对FTP服务器执行命令,查询文件名、下载、上传等等命令都是利用这个通道来执行的。

    步骤二:通知FTP服务端使用Active且告诉连接的端口号
    FTP服务器端的端口 21号主要用在命令的执行,但是当牵涉到数据流时,就不是使用这个连接了。客户端在需要数据的情况下,会告知服务器端要用什么方式连接,如果是主动模式连接,客户端会随机启用一个端口(port BB),且通过命令通道告知FTP服务器这两个信息,并等待FTP服务器端的连接。

    步骤三:FTP服务端主动向客户端连接
    FTP服务器由命令通道了解客户端的需求后,会主动由port 20向客户端port BB连接,这个连接当然也会经过三次握手。此时FTP的客户端与服务器端建立了两条连接,分别用在命令的执行和数据的传输。而默认FTP服务端使用主动连接端口就是port 20。这样就建立起"命令"与"数据传输"两个通道。

    注意:
    第1点:数据传输通道是在有数据传输的行为才会建立连接,并不是一开始连接到FTP服务器就立刻建立的数据通道。
    第2点:命令通道的FTP默认为port 21。数据传输的FTP-DATA默认为port 20。
    第3点:这两个端口的工作原理是不一样的,而且,两者的连接发起端是不一样的。首先port 21接受来自客户端的主动连接, port 20则是FTP服务器主动连接到客户端。

    被动模式

    1.定义
    在被动模式下,客户端通过PASV命令获得服务器端IP地址和数据端口,然后向服务器端发起连接请求,从而建立数据连接。因此服务器端只是被动地监听在指定端口上的请求。
    当连接某个FTP服务器失败时可以试着修改FTP客户端工具配置,改变传输模式,这样或许能够连接成功。

    2、FTP被动连接示意图
    在这里插入图片描述

    3、被动模式分析

    步骤一:客户端与服务器建立命令通道
    同样需要建立命令通道,通过三次握手就可以建立起这个通道了。

    步骤二:客户端发起PASV的连接要求
    当使用数据通道命令时,客户端可通过命令通道发起PASV的被动式连接要求,并等待服务器的回应。

    步骤三:FTP服务器启动数据端口,并通知客户端连接
    如果你使用的FTP服务器是能够处理被动式连接的,此时FTP服务器会先启动一个监听端口。这个端口号码可以是随机的,也可以自定义某个范围的端口。然后FTP服务器会通过命令通道告知客户端已经启动的端口(port PASV),并等待客户端的连接。

    步骤四:客户端随机取用大于1024的端口进行连接
    最后你的客户端会随机取用一个大于1024端口来进行对FTP服务器port PASV连接。如果一切都顺利,那么FTP数据就可以通过port BB和port PASV来传送了。

    注意:
    第1点:被动模式FTP数据通道是由客户端向服务器端发起连接的。

    4、被动模式抓包分析
    通过ftp到ftp.ksu.edu.tw这个FTP服务器,我们抓一下包,下面是登录过程。
    第一步:客户端发起命令通道的三次握手。
    第二步:客户端发起PASV的连接请求。
    第三步:服务器端启动数据端口,并告知客户端该端口号。
    第四步:客户端发起数据通道的三次握手。

    SSL/TLS 协议

    原文地址:https://cshihong.github.io/2019/05/09/SSL%E5%8D%8F%E8%AE%AE%E8%AF%A6%E8%A7%A3/
    SSL VPN可参考:SSL VPN技术原理
    赏月斋 慎终如始 宁静致远 博客园

    SSL简介

    (1) SSL和TLS

    SSL (Secure Sockets Layer)安全套接层。是由Netscape公司于1990年开发,用于保障Word Wide Web(WWW)通讯的安全。主要任务是提供私密性,信息完整性和身份认证。1994年改版为SSLv2,1995年改版为SSLv3.
    TLS(Transport Layer Security)安全传输层协议,)用于在两个通信应用程序之间提供保密性和数据完整性。该标准协议是由IETF于1999年颁布,整体来说TLS非常类似SSLv3,只是对SSLv3做了些增加和修改。

    (2) SSL协议介绍

    SSL是一个不依赖于平台和运用程序的协议,位于TCP/IP协议与各种应用层协议之间,为数据通信提高安全支持。
    在这里插入图片描述

    (3) SSL加密知名协议

    1. HTTP over SSL:
      简写https,加密网页浏览是设计SSL的初衷,HTTP也是第一个使用SSL保障安全的应用层协议。
      当Netscape在它的Navigator里面运用HTTP over SSL的时候,使用https://来标识HTTP over SSL,因此我常见的https的全称就是HTTP over SSL。后来HTTPS在RFC2818被标准化。HTTPS工作在443端口,而HTTP默认工作在80端口。

    2. Email over SSL:
      类似于HTTP over SSL,邮件协议例如:
      SMTP,POP3、IMAP也能支持SSL。
      SMTP over TLS的标准文档在RFC2487
      POP3和IMAP over TLS的标准化文档在RFC2595.

    SSL协议结构

    在这里插入图片描述
    SSL的体系结构中包含两个协议子层,其中底层是SSL记录协议层(SSL Record Protocol Layer);高层是SSL握手协议层(SSL HandShake Protocol Layer)。

    (1) SSL协议主要分为两层

    SSL记录协议层的作用是为高层协议提供基本的安全服务。SSL记录协议针对HTTP协议进行了特别的设计,使得超文本的传输协议HTTP能够在SSL运行。纪录封装各种高层协议,具体实施压缩解压缩、加密解密、计算和校验MAC等与安全有关的操作。
    SSL握手协议层包括SSL握手协议(SSL HandShake Protocol)、SSL密码参数修改协议(SSL Change Cipher Spec Protocol)和SSL告警协议(SSL Alert Protocol)。握手层的这些协议用于SSL管理信息的交换,允许应用协议传送数据之间相互验证,协商加密算法和生成密钥等。
    SSL握手协议的作用是协调客户和服务器的状态,使双方能够达到状态的同步。

    (2) 记录协议和握手协议

    SSL记录协议:它建立在可靠的传输(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能。

    SSL握手协议:它建立在SSL记录协议之上,用于在实际的数据传输开始之前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。

    (3) SSL建立阶段与IPSec VPN类比的话,可以分为两个大阶段

    1. SSL建立的第一阶段:Handshake phase(握手阶段):
    • 协商加密算法
    • 认证服务器
    • 建立用于加密和MAC(Message Authentication Code)用的密钥

    该阶段类似于IPSec VPN IKE的作用。

    1. SSL建立第二阶段:Secure data transfer phase(安全的数据传输阶段):

    在已经建立的SSL连接里安全的传输数据。

    该阶段类似于IPSec VPN ESP的作用

    SSL原理(SSL建立)握手协议总过程

    SSL建立总过程
    在用SSL进行通信之前,首先要使用SSL的Handshake协议在通信两端握手,协商数据传输中要用到的相关安全参数(如加密算法、共享密钥、产生密钥所要的材料等),并对对端的身份进行验证。
    SSL的建立过程总共有13个包,第一次建立至少需要9个包。

    SSL建立第一阶段 ClientHello&ServerHello

    客户端首先发送ClientHello消息到服务端,服务端收到ClientHello消息后,再发送ServerHello消息回应客户端。
    SSL建立第一阶段报文交换示意图
    握手第一步是客户端向服务端发送 Client Hello 消息,这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件(Support Ciphers)和 SSL Version 等信息。
    ClinetHello报文抓包示例

    ClientHello中涉及到的消息具体如下:

    • 客户端版本
    • 按优先级列出客户端支持的协议版本,首选客户端希望支持的最新协议版本。
    • 客户端随机数Random
    • 会话ID(Session id)。如果客户端第一次连接到服务器,那么这个字段就会保持为空。上图中该字段为空,说明这是第一次连接到服务器。。如果该字段不为空,说明以前是与服务器有连接的,在此期间,服务器将使用Session ID映射对称密钥,并将Session ID存储在客户端浏览器中,为映射设置一个时间限。如果浏览器将来连接到同一台服务器(在时间到期之前),它将发送Session ID,服务器将对映射的Session ID进行验证,并使用以前用过的对称密钥来恢复Session,这种情况下不需要完全握手。也叫作SSL会话恢复。后面会有介绍。
    • 加密套件。客户端会给服务器发送自己已经知道的密码套件列表,这是由客户按优先级排列的,但完全由服务器来决定发送与否。TLS中使用的密码套件有一种标准格式。上面的报文中,客户端发送了74套加密套件。服务端会从中选出一种来作为双方共同的加密套件。
    • 压缩方法。为了减少带宽,可以进行压缩。但从成功攻击TLS的事例中来看,其中使用压缩时的攻击可以捕获到用HTTP头发送的参数,这个攻击可以劫持Cookie,这个漏洞我们称为CRIME。从TLS 1.3开始,协议就禁用了TLS压缩。
    • 扩展包。其他参数(如服务器名称,填充,支持的签名算法等)可以作为扩展名使用。

    这些是客户端问候的一部分,如果已收到客户端问候,接下来就是服务器的确认,服务器将发送服务器问候。
    收到客户端问候之后服务器必须发送服务器问候信息,服务器会检查指定诸如TLS版本和算法的客户端问候的条件,如果服务器接受并支持所有条件,它将发送其证书以及其他详细信息,否则,服务器将发送握手失败消息。
    如果接受,第二步是服务端向客户端发送 Server Hello 消息,这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件,这个套件决定了后续加密和生成摘要时具体使用哪些算法,另外还会生成一份随机数 Random2。注意,至此客户端和服务端都拥有了两个随机数(Random1+ Random2),这两个随机数会在后续生成对称秘钥时用到。
    ServerHello报文抓包
    ServerHello中涉及到的具体参数:

    • 服务器版本Version。服务器会选择客户端支持的最新版本。
    • 服务器随机数Random。服务器和客户端都会生成32字节的随机数。用来创建加密密钥。
    • 加密套件。服务器会从客户端发送的加密套件列表中选出一个加密套件。
    • 会话ID(Session ID)。服务器将约定的Session参数存储在TLS缓存中,并生成与其对应的Session id。它与Server Hello一起发送到客户端。客户端可以写入约定的参数到此Session id,并给定到期时间。客户端将在Client Hello中包含此id。如果客户端在此到期时间之前再次连接到服务器,则服务器可以检查与Session id对应的缓存参数,并重用它们而无需完全握手。这非常有用,因为服务器和客户端都可以节省大量的计算成本。在涉及亚马逊和谷歌等流量巨大的应用程序时,这种方法存在缺点。每天都有数百万人连接到服务器,服务器必须使用Session密钥保留所有Session参数的TLS缓存。这是一个巨大的开销。为了解决这个问题,在扩展包里加入了Session Tickets, 在这里,客户端可以在client hello中指定它是否支持Session Ticket。然后,服务器将创建一个新的会话票证(Session Ticket),并使用只有服务器知道的经过私钥加密的Session参数。它将存储在客户端上,因此所有Session数据仅存储在客户端计算机上,但Ticket仍然是安全的,因为该密钥只有服务器知道。此数据可以作为名为Session Ticket的扩展包含在Client Hello中。
    • 压缩算法。如果支持,服务器将同意客户端的首选压缩方法。
    • 扩展包。

    这个阶段之后,客户端服务端知道了下列内容:

    • SSL版本
    • 密钥交换、信息验证和加密算法
    • 压缩方法
    • 有关密钥生成的两个随机数。

    SSL建立第二阶段 服务器向客户端发送消息

    SSL建立第二阶段报文交换示意图
    服务器启动SSL握手第2阶段,是本阶段所有消息的唯一发送方,客户机是所有消息的唯一接收方。该阶段分为4步:

    • 证书:服务器将数字证书和到根CA整个链发给客户端,使客户端能用服务器证书中的服务器公钥认证服务器。
    • 服务器密钥交换(可选):这里视密钥交换算法而定
    • 证书请求:服务端可能会要求客户自身进行验证。
    • 服务器握手完成:第二阶段的结束,第三阶段开始的信号

    (1) Certificate消息(可选)—第一次建立必须要有证书。

    一般情况下,除了会话恢复时不需要发送该消息,在SSL握手的全流程中,都需要包含该消息。消息包含一个X.509证书,证书中包含公钥,发给客户端用来验证签名或在密钥交换的时候给消息加密。
    这一步是服务端将自己的证书下发给客户端,让客户端验证自己的身份,客户端验证通过后取出证书中的公钥。
    服务器给客户端发送的证书报文

    (2) Server Key Exchange(可选)

    根据之前在ClientHello消息中包含的CipherSuite信息,决定了密钥交换方式(例如RSA或者DH),因此在Server Key Exchange消息中便会包含完成密钥交换所需的一系列参数。
    Server Key Exchange报文
    因为这里是DH算法,所以需要发送服务器使用的DH参数。RSA算法不需要这一步。
    在Diffie-Hellman中,客户端无法自行计算预主密钥; 双方都有助于计算它,因此客户端需要从服务器获取Diffie-Hellman公钥。
    由上图可知,此时密钥交换也由签名保护。

    (3) Certificate Request(可选)------可以是单向的身份认证,也可以双向认证

    这一步是可选的,如果在对安全性要求高的常见可能用到。服务器用来验证客户端。服务器端发出Certificate Request消息,要求客户端发他自己的证书过来进行验证。该消息中包含服务器端支持的证书类型(RSA、DSA、ECDSA等)和服务器端所信任的所有证书发行机构的CA列表,客户端会用这些信息来筛选证书。

    (4) Server Hello Done

    该消息表示服务器已经将所有信息发送完毕,接下来等待客户端的消息。
    Server Hello Done报文

    SSL建立第三阶段 客户端向服务器发送消息

    客户端收到服务器发送的一系列消息并解析后,将本端相应的消息发送给服务器。
    SSL建立第三阶段报文交换示意图
    客户机启动SSL握手第3阶段,是本阶段所有消息的唯一发送方,服务器是所有消息的唯一接收方。该阶段分为3步:

    • 证书(可选):为了对服务器证明自身,客户要发送一个证书信息,这是可选的,在IIS中可以配置强制客户端证书认证。
    • 客户机密钥交换(Pre-master-secret):这里客户端将预备主密钥发送给服务端,注意这里会使用服务端的公钥进行加密。
    • 证书验证(可选),对预备秘密和随机数进行签名,证明拥有(a)证书的公钥。

    (1) Certificate(可选)

    如果在第二阶段服务器端要求发送客户端证书,客户端便会在该阶段将自己的证书发送过去。服务器端在之前发送的Certificate Request消息中包含了服务器端所支持的证书类型和CA列表,因此客户端会在自己的证书中选择满足这两个条件的第一个证书发送过去。若客户端没有证书,则发送一个no_certificate警告。

    (2) Client Key exchange

    根据之前从服务器端收到的随机数,按照不同的密钥交换算法,算出一个pre-master,发送给服务器,服务器端收到pre-master算出main master。而客户端当然也能自己通过pre-master算出main master。如此以来双方就算出了对称密钥。

    如果是RSA算法,会生成一个48字节的随机数,然后用server的公钥加密后再放入报文中。如果是DH算法,这是发送的就是客户端的DH参数,之后服务器和客户端根据DH算法,各自计算出相同的pre-master secret.
    Clinet Key exchange报文
    本消息在给服务器发送的过程中,使用了服务器的公钥加密。服务器用自己的私钥解密后才能得到pre-master key.(向服务器证明自己的确持有客户端证书私钥。)

    (3) Certificate verify(可选)

    只有在客户端发送了自己证书到服务器端,这个消息才需要发送。其中包含一个签名,对从第一条消息以来的所有握手消息的HMAC值(用master_secret)进行签名。

    SSL建立第四阶段 完成握手协议,建立SSL连接

    SSL建立第四阶段报文交换示意图
    客户机启动SSL握手第4阶段,使服务器结束。该阶段分为4步,前2个消息来自客户机,后2个消息来自服务器。
    建立起一个安全的连接,客户端发送一个Change Cipher Spec消息,并且把协商得到的CipherSuite拷贝到当前连接的状态之中。然后,客户端用新的算法、密钥参数发送一个Finished消息,这条消息可以检查密钥交换和认证过程是否已经成功。其中包括一个校验值,对客户端整个握手过程的消息进行校验。服务器同样发送Change Cipher Spec消息和Finished消息。握手过程完成,客户端和服务器可以交换应用层数据进行通信。

    (1) ChangeCipherSpec

    编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送(ChangeCipherSpec是一个独立的协议,体现在数据包中就是一个字节的数据,用于告知服务端,客户端已经切换到之前协商好的加密套件(Cipher Suite)的状态,准备使用之前协商好的加密套件加密数据并传输了)。
    Cipher Spec Message报文
    是一条事件消息。

    (2) Clinet Finished

    客户端握手结束通知, 表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验(使用HMAC算法计算收到和发送的所有握手消息的摘要,然后通过RFC5246中定义的一个伪函数PRF计算出结果,加密后发送。此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。)

    (3) Server Finished

    服务端握手结束通知。

    使用私钥解密加密的Pre-master数据,基于之前(Client Hello 和 Server Hello)交换的两个明文随机数 random_C 和 random_S,计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);计算之前所有接收信息的 hash 值,然后解密客户端发送的 encrypted_handshake_message,验证数据和密钥正确性;发送一个 ChangeCipherSpec(告知客户端已经切换到协商过的加密套件状态,准备使用加密套件和 Session Secret加密数据了);服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端,以验证之前通过握手建立起来的加解密通道是否成功。

    根据之前的握手信息,如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证,则说明握手通道已经建立成功,接下来,双方可以使用上面产生的Session Secret对数据进行加密传输了。

    消息验证代码(HMAC)和TLS数据完整性

    当服务器或客户端使用主密钥加密数据时,它还会计算明文数据的校验和(哈希值),这个校验和称为消息验证代码(MAC)。然后在发送之前将MAC包含在加密数据中。密钥用于从数据中生成MAC,以确保传输过程中攻击者无法从数据中生成相同的MAC,故而MAC被称为HMAC(哈希消息认证码)。另一方面,在接收到消息时,解密器将MAC与明文分开,然后用它的密钥计算明文的校验和,并将其与接收到的MAC进行比较,如果匹配,那我们就可以得出结论:数据在传输过程中没有被篡改。

    几个重要的secret key

    (1) PreMaster secret

    PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。PreMaster secret前两个字节是TLS的版本号,这是一个比较重要的用来核对握手数据的版本号。服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比,如果版本号变低,则说明被串改,则立即停止发送任何消息。

    (2) Master secret

    由于最后通过交换,客户端和服务端都会有Pre-master和随机数,这个随机数将作为后面产生Master secret的种子,结合PreMaster secret,客户端和服务端将计算出同样的Master secret。
    在这里插入图片描述
    为了保证信息的完整性和机密性,SSL需要有六个加密密钥:四个密钥和两个IV。为了信息的可信性,客户端需要一个密钥(HMAC),为了加密要有一个密钥,为了分组加密要一个IV,服务器也是如此。SSL需要的密钥是单向的,不同于那些在其他方向的密钥。如果在一个方向上有攻击,这种攻击在其他方向是没影响的。生成过程如下:
    在这里插入图片描述
    主密钥是由一系列的Hash值组成。
    在这里插入图片描述
    master_secret = PRF(pre_master_secret,“master secret”,ClientHello.random + ServerHello.random)[0…47];
    在这里插入图片描述
    根据要求,有4个密钥用于加密和验证每个消息的完整性,他们是:
    客户端写入加密密钥:客户端用来加密数据,服务器用来解密数据。
    服务器写入加密密钥:服务器用来加密数据,客户端用来解密数据。
    客户端写入MAC密钥:客户端用来创建MAC,服务器用来验证MAC。
    服务器写入MAC密钥:服务器用来创建MAC,客户端用来验证MAC。

    SSL会话恢复
    会话恢复是指只要客户端和服务器已经通信过一次,它们就可以通过会话恢复的方式来跳过整个握手阶段二直接进行数据传输。

    SSL会话恢复过程
    SSL采用会话恢复的方式来减少SSL握手过程中造成的巨大开销。

    为了加快建立握手的速度,减少协议带来的性能降低和资源消耗(具体分析在后文),TLS 协议有两类会话缓存机制:
    会话标识 session ID: 由服务器端支持,协议中的标准字段,因此基本所有服务器都支持,服务器端保存会话ID以及协商的通信信息,Nginx 中1M 内存约可以保存4000个 session ID 机器相关信息,占用服务器资源较多;
    会话记录 session ticket :t需要服务器和客户端都支持,属于一个扩展字段,支持范围约60%(无可靠统计与来源),将协商的通信信息加密之后发送给客户端保存,密钥只有服务器知道,占用服务器资源很少。
    二者对比,主要是保存协商信息的位置与方式不同,类似与 http 中的 session 与 cookie。二者都存在的情况下,(nginx 实现)优先使用 session_ticket。

    会话恢复具体过程(Session ID机制):
    如果客户端和服务器之间曾经建立了连接,服务器会在握手成功后返回 session ID,并保存对应的通信参数在服务器中;
    如果客户端再次需要和该服务器建立连接,则在 client_hello 中 session ID 中携带记录的信息,发送给服务器;
    服务器根据收到的 session ID 检索缓存记录,如果没有检索到货缓存过期,则按照正常的握手过程进行;
    如果检索到对应的缓存记录,则返回 change_cipher_spec 与 encrypted_handshake_message 信息,两个信息作用类似,encrypted_handshake_message 是到当前的通信参数与 master_secret的hash 值;
    如果客户端能够验证通过服务器加密数据,则客户端同样发送 change_cipher_spec 与 encrypted_handshake_message 信息;
    服务器验证数据通过,则握手建立成功,开始进行正常的加密数据通信。

    会话恢复具体过程( session ticket):
    如果客户端和服务器之间曾经建立了连接,服务器会在 new_session_ticket 数据中携带加密的 session_ticket 信息,客户端保存;
    如果客户端再次需要和该服务器建立连接,则在 client_hello 中扩展字段 session_ticket 中携带加密信息,一起发送给服务器;
    服务器解密 sesssion_ticket 数据,如果能够解密失败,则按照正常的握手过程进行;
    如果解密成功,则返回 change_cipher_spec 与 encrypted_handshake_message 信息,两个信息作用与 session ID 中类似;
    如果客户端能够验证通过服务器加密数据,则客户端同样发送 change_cipher_spec与encrypted_handshake_message 信息;
    服务器验证数据通过,则握手建立成功,开始进行正常的加密数据通信。

    SSL记录协议:
    SSL记录协议主要用来实现对数据块的分块、加密解密、压缩与解压缩、完整性检查及封装各种高层协议。
    SSL记录协议结构
    每个SSL记录主要包含以下信息:
    内容类型
    协议版本号,目前有2.0和3.0版本
    记录数据的长度
    数据由载荷
    散列算法计算消息认证代码
    记录
    SSL记录协议工作原理
    将消息分割为多个片段;
    对每个片段进行压缩
    加上片段编号(防止重放攻击)计算消息验证码MAC值(保证数据完整性),追加在压缩片段
    对称密码加密;
    加上数据类型、版本号、压缩后的长度组成的报头, 就是最终的报文数据;

    应用数据传输:
    在所有的握手阶段都完成之后,就可以开始传送应用数据了。应用数据在传输之前,首先要附加上MAC secret,然后再对这个数据包使用write encryption key进行加密。在服务端收到密文之后,使用Client write encryption key进行解密,客户端收到服务端的数据之后使用Server write encryption key进行解密,然后使用各自的write MAC key对数据的完整性包括是否被串改进行验证。

    非对称加密算法

    非对称加密算法需要两个密钥:公开密钥(publickey)和私有密钥(privatekey)。公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密。

    HTTPS协议中,前面的握手过程,服务器会将公钥发给客户端,客户端验证后生成一个密钥用公钥加密后发送给服务器,成功后建立通信。

    通信过程客户端将请求数据用得到的公钥加密后,发给服务器,服务器用私钥解密。服务器用客户端给的密钥加密响应报文,发回给客户端,客户端用自己存的密钥解密。

    忽略掉其他例如确定协议和版本号之类的环节,提炼出来的重要环节如下:
    在这里插入图片描述
    公私玥A用于非对称式加密,密钥B只用于普通的对称式加密。

    简而言之就是这样,那么问题来了:你作为一个中间人,你没有服务器私钥A,是不能解密客户端发送的内容的,如果你没有客户端自己生成的密钥B,所以你也不能解密客户端发过去的内容的。

    请注意:这两个私钥都是两端各自保存,而私钥A是只保存在服务器上,从不对外发送的。
    在这里插入图片描述
    结果就是,你收发的数据,他都能看到------------------但是他不能解密,看不懂。

    这只是最普通的劫持HTTP的方式,HTTPS就是为了解决题主所说的这个中间人攻击而产生的,然而题主并没有去理解HTTPS的工作原理,而用HTTP的原始思路继续去思考HTTPS,所以题主这个方法是完全不可行的。

    继续往下想,或许有人会觉得:

    如果你自己签发一对非对称式公私钥C,还有密钥D,然后作为一个中间人。在一开始的通信环节,用公私钥C替代公私钥A,用密钥D替代密钥B。这样分发给对应的服务器和客户端,这样他们发给自己的信息,自己都能解密。然后自己再用真正的公钥A把解密后的信息重新加密发给服务器骗取响应报文,把响应报文用密钥B(前面客户端用公钥C加密后,被中间人用私钥C解密的刀)重新加密发回给客户端骗取新的请求报文。

    这样岂不是可以瞒天过海?

    那么在图中所示的验证环节,因为你的证书是自己签发的,所以证书跟指纹拿去去系统里可信颁发机构的证书那一对,肯定对不上。
    在这里插入图片描述
    例如我用Fiddler给自己签发了个证书,因为颁发者不在系统受信任证书颁发机构里,会直接报警:
    在这里插入图片描述
    如果你要假冒其他机构颁发证书,因为你没有颁发机构的密钥,那么你颁发的证书,结果指纹肯定没办法对上,还是一样会报警。
    在这里插入图片描述
    系统信任的颁发机构一般都是权威的大机构,当然你也可以自己导入自己信任的机构的证书,用来验证签名。
    在这里插入图片描述
    如果要实现HTTPS下的中间人攻击,你应该让自己的根证书进入系统里,让自己成为裁判。

    这是HTTPS中间人攻击中最难也是最简单的一点------毕竟用户很好骗。
    在这里插入图片描述
    你可以这么做,或者跟上一张图证书中的第三第四行所示的那么做。

    还有人就说了,我可以让用户回落到HTTP协议啊,中间人用HTTPS跟服务器通信,然后用HTTP跟客户端通信------要知道大部分用户在地址栏输入URL时,并没有指定协议的习惯,都是打www开头而不是打https://开头,能用HTTPS全是Web Server上80端口301 Location到HTTPS的功劳。

    看起来似乎中间人充当了一个替换页面里HTTPS资源到HTTP的反向代理,好像可行性还是很高。

    但是只要利用HSTS(HTTP Strict Transport Security,RFC6797)就可以解决这个问题。通过在HTTP Header中加入Strict-Transport-Security的声明,告诉浏览器在一定时间内必须通过HTTPS协议访问本域名下的资源。

    这种情况下,只要用户曾经在安全网络环境下访问过一次某站,中间人在指定时间内也无法让其回落到HTTP。

    原文地址:https://www.zhihu.com/question/22795329

    展开全文
  • EtherType :以太网类型字段及值

    万次阅读 多人点赞 2017-03-23 17:30:56
    Ethernet II类型以太网帧的最小长度为64字节(6+6+2+46+4),最大长度为1518字节(6+6+2+1500+4)。其中前12字节分别标识出发送数据帧的源节点MAC地址和接收数据帧的目标节点MAC地址。(注:ISL封装后

    Ethernet II即DIX 2.0:Xerox与DEC、Intel在1982年制定的以太网标准帧格式。Cisco名称为:ARPA

    Ethernet II类型以太网帧的最小长度为64字节(6+6+2+46+4)最大长度为1518字节(6+6+2+1500+4)。其中前12字节分别标识出发送数据帧的源节点MAC地址和接收数据帧的目标节点MAC地址。(注:ISL封装后可达1548字节,802.1Q封装后可达1522字节)

    接下来的2个字节标识出以太网帧所携带的上层数据类型,如下:

    IPv4: 0x0800

    ARP:0x0806

    PPPoE:0x8864

    802.1Q tag: 0x8100

    IPV6: 0x86DD

    MPLS Label:0x8847

    在不定长的数据字段后是4个字节的帧校验序列(Frame. Check Sequence,FCS)



    EtherType 是以太帧里的一个字段,用来指明应用于帧数据字段的协议。根据 IEEE802.3,Length/EtherType 字段是两个八字节的字段,含义两者取一,这取决于其数值。在量化评估中,字段中的第一个八位字节是最重要的。而当字段值大于等于十进制值 1536 (即十六进制为 0600)时, EtherType 字段表示为 MAC 客户机协议(EtherType 解释)的种类。该字段的长度和 EtherType 详解是互斥的。

    该类字段值取自 IEEE EtherType 字段寄存器。EtherType 字段是个极限空间,因此其分配是有限的。只有开发新的数据传输协议的人员需要使用 EtherType 字段,而不管他们实际上是否真正生产任何设备。IEEE RAC EtherType 字段批准权威机构负责检查和批准 EtherType 字段。

    知名协议已经分配了 EtherType 值,下面表格中列出了 EtherType 字段中常用值及其对应的协议:

    Ethertype 
    ( 十六进制 )

    协议

    0x0000 - 0x05DC

    IEEE 802.3 长度

    0x0101 – 0x01FF

    实验

    0x0600

    XEROX NS IDP

    0x0660 
    0x0661

    DLOG

    0x0800

    网际协议(IP)

    0x0801

    X.75 Internet

    0x0802

    NBS Internet

    0x0803

    ECMA Internet

    0x0804

    Chaosnet

    0x0805

    X.25 Level 3

    0x0806

    地址解析协议(ARP : Address Resolution Protocol)

    0x0808

    帧中继 ARP (Frame Relay ARP) [RFC1701]

    0x6559

    原始帧中继(Raw Frame Relay) [RFC1701]

    0x8035

    动态 DARP (DRARP:Dynamic RARP)
    反向地址解析协议(RARP:Reverse Address Resolution Protocol)

    0x8037

    Novell Netware IPX

    0x809B

    EtherTalk

    0x80D5

    IBM SNA Services over Ethernet

    0x 80F 3

    AppleTalk 地址解析协议(AARP:AppleTalk Address Resolution Protocol)

    0x8100

    以太网自动保护开关(EAPS:Ethernet Automatic Protection Switching)

    0x8137

    因特网包交换(IPX:Internet Packet Exchange)

    0x 814C

    简单网络管理协议(SNMP:Simple Network Management Protocol)

    0x86DD

    网际协议v6 (IPv6,Internet Protocol version 6)

    0x880B

    点对点协议(PPP:Point-to-Point Protocol)

    0x 880C

    通用交换管理协议(GSMP:General Switch Management Protocol)

    0x8847

    多协议标签交换(单播) MPLS:Multi-Protocol Label Switching <unicast>)

    0x8848

    多协议标签交换(组播)(MPLS, Multi-Protocol Label Switching <multicast>)

    0x8863

    以太网上的 PPP(发现阶段)(PPPoE:PPP Over Ethernet <Discovery Stage>)

    0x8864

    以太网上的 PPP(PPP 会话阶段) (PPPoE,PPP Over Ethernet<PPP Session Stage>)

    0x88BB

    轻量级访问点协议(LWAPP:Light Weight Access Point Protocol)

    0x88CC

    链接层发现协议(LLDP:Link Layer Discovery Protocol)

    0x8E88

    局域网上的 EAP(EAPOL:EAP over LAN)

    0x9000

    配置测试协议(Loopback)

    0x9100

    VLAN 标签协议标识符(VLAN Tag Protocol Identifier)

    0x9200

    VLAN 标签协议标识符(VLAN Tag Protocol Identifier)

    0xFFFF

    保留

    EtherType :以太网类型字段及值

    EtherType :以太网类型字段及值


    2. ARP (ARP Header长度:8字节)

    硬件类型:1 表示以太网

    协议类型:和Ethernet数据帧中类型字段相同

    OP操作字段:1 表示ARP请求

    2 表示ARP应答

    3 表示RARP请求

    4 表示RARP应答

    3. 802.1q VLAN数据帧(4字节)

    基于802.1Q的VLAN帧格式

    • Type:长度为2字节,取值为0x8100,表示此帧的类型为802.1Q Tag帧。
    • PRI:长度为3比特,可取0~7之间的值,表示帧的优先级,值越大优先级越高。该优先级主要为QoS差分服务提供参考依据(COS)。
    • VLAN Identifier (VID) : 长度12bits,可配置的VLAN ID取值范围为1~4094。通常vlan 0和vlan 4095预留,vlan1为缺省vlan,一般用于网管。

      QinQ帧格式

      4. PPP帧(除去信息字段后长度为:8字节)

      PPP报文格式

      PPP报文的内容是指Address、Control、Protocol和Information四个域的内容。各字段的含义如下。

    • Flag域Flag域标识了一个物理帧的起始和结束,该字节为0x7E。
    • Address域PPP协议是被运用在点对点的链路上,它可以唯一标识对方。因此使用PPP协议互连的两个通信设备无须知道对方的数据链路层地址。所以该字节已无任何意义,按照协议的规定将该字节填充为全1的广播地址。
    • Control域同Address域一样,PPP数据帧的Control域也没有实际意义,按照协议的规定通信双方将该字节的内容填充为0x03。Address和Control域一起表示了此报文为PPP报文,即PPP报文头为FF03。
    • Protocol域协议域可用来区分PPP数据帧中信息域所承载的数据报文的内容。

    协议代码

    协议类型

    0021

    Internet Protocol

    8021

    Internet Protocol Control Protocol

    C021

    Link Control Protocol

    C023

    Password Authentication Protocol

    C223

    Challenge Handshake Authentication Protocol

    • Information域信息域最大长度是1500字节,其中包括填充域的内容。信息域的最大长度等于PPP协议中MRU(Maximum Receive Unit)的缺省值。

      5. HDLC帧(除去信息字段后长度为:8字节)

      HDLC帧格式

      各字段的含义解释:

    字段

    长度(字节)

    含义

    Protocol

    2

    协议字段。表示Information域中的数据封装的协议类型。

    Information

    N

    信息字段。可以是任意的二进制比特串,长度未作限定。其上限由FCS字段或通信节点的缓冲容量来决定,目前国际上用得较多的是1000~2000比特,而下限可以是0,即无信息字段。但是监控帧中不可有信息字段。

    6. PPPoE报文(报文头长度为6字节)

    windows系统pppoe MTU大小

    默认和最大 PPPoE MTU 大小为 1,480 字节。对于某些 Internet 服务提供商 (ISP),您可能需要将 PPPoE 连接的 MTU 大小降至 1,400  1,480 之间的一个值(例如 1,454)。不要将 MTU 大小设置为小于 1,400

    路由器pppoe拨号时MTU为1492

    7. MPLS Label

    Label报文格式:

    MPLS uses a 32-bit label field that contains the following information:

    • 20-bit label (a number)
    • 3-bit experimental field (usually used to carry IP precedence value)
    • 1-bit bottom-of-stack indicator (indicates whether this is the last label before the IP header)
    • 8-bit TTL (equal to the TTL in IP header)used to prevent indefinite looping of packets.

    展开全文
  • 在开始阅读之前,如果你对已介绍的总线技术还不了解的话,可以先阅读以下文章快速温习一下,等补完车载以太网和MOST,汽车总线技术楼主基本分享结束了。说一说LIN总线CAN总线基础(一)CAN总线基础(下)CAN FD 介绍...
  • 一、ARP协议以太网中传输的帧结构如下图所示: 二、 数据包每个部分介绍: 三、ARP 请求抓包截图 一、ARP协议以太网中传输的帧结构如下图所示: 二、 数据包每个部分介绍: 以太网目的地址(6Byte)...
  • 网络协议以太网协议解析

    千次阅读 2020-04-18 18:03:34
    Ethernet :以太网协议,用于实现链路层的数据传输和地址封装(MAC) 封装原理: 以太网的数据帧格式如下图所示: 它由6个字节的目的MAC地址,6个字节的源MAC地址,2个字节的类型域(用于标示封装在这...
  • 以太网主要协议关系介绍2. 协议介绍及帧结构2.1 媒体访问控制子层协议MAC2.2 地址解析协议ARP2.2.1ARP帧结构2.2.2 ARP协议工作原理2.3 网际互连协议IP2.3.1 IP协议帧2.3.2 IP数据报分片重组2.4 互联网控制消息协议...
  • 本文针对常用网络协议报文结构进行讲解,并提供报文示例 数据链路层协议: 以太网数据帧、ARP协议、PPP协议、PPPoE协议;网络层的协议: IP协议;传输层的协议:TCP协议、UDP协议、ICMP协议 各位觉得有什么其它常用...
  • 以太网数据帧格式及ARP协议

    千次阅读 2020-08-29 15:59:52
    在物理层上看,一个完整的以太网帧有7个字段,事实上,前两个字段并不能算是真正意义上的以太网数据帧,它们是以太网在物理层上发送以太网数据时添加上去的。为了实现底层数据的正确阐述,物理层使用7个字节前同步码...
  • 以太网类型字段

    2019-12-26 10:14:15
    1.0x800 IP数据报 2.0x806 ARP请求或应答报文 3.0x835 RARP请求或应答报文
  • 以太网类型总结

    万次阅读 2016-09-12 09:27:06
    EtherType :以太网类型字段及值 EtherType 是以太帧里的一个字段,用来指明应用于帧数据字段协议。根据 IEEE802.3,Length/EtherType 字段是两个八字节的字段,含义两者取一,这取决于其数值。在量化评估中...
  • 以太网UDP协议讲解

    2021-08-06 11:22:30
    当无线网络和卫星出现以后,现有的协议在和它们相连的时候出现了问题,所以需要一种新的参考体系结构。这个体系结构在它的两个主要协议出现以后,被称为TCP/IP参考模型(TCP/IP reference model); 2.四层模型 TCP/
  • 以太网数据包协议格式MAC层ARP层IP层ICMPUDPTCP、UDP数据包大小的限制 MAC层 帧格式: 帧介绍: 帧间隙(IFG): 网络设备和组件在接收一个帧之后,需要一段短暂的时间来恢复并为接收下一帧做准备。 不管 10M/100M/...
  • ARP协议报文格式及ARP表简述

    千次阅读 2020-11-11 17:36:21
    ARP(Address Resolution Protocal,地址解析协议)是将IP地址解析为以太网的MAC地址(或者称为物理地址)的协议。在局域网中,当主机或其他网络设备有数据要发送给另一个主机或设备时,它必须知道对
  • 这几天完成一个对比以太网帧的程序(c语言),老师给了以太网帧头部和IP报文头部的结构体,跟实际抓取到的数据包的格式是相同的。 以太网帧头部的数据结构: typedef struct { unsigned char dest_mac[6]; ...
  • 以太网完整协议(一)

    万次阅读 多人点赞 2017-05-03 15:54:31
    一、太网中数据帧结构 以太网是目前最流行的一种局域网组网技术(其他常见局域网...在物理层上看,一个完整的以太网帧有7个字段,事实上,前两个字段并不能算是真正意义上的以太网数据帧,它们是以太网在物理层上发送
  • 给大家简单梳理一下几种学习中常会出现的协议格式,协议格式的了解在咋们学习过程中还是挺重要的,可以更加方便咋们便于 一、 HDLC协议 HDLC叫高级链路控制协议(High Level Data Link Control)。该协议一般...
  • 以太网帧、IP 帧、UDP/TCP帧、http 报文结构解析

    万次阅读 多人点赞 2018-11-16 23:18:26
    OSI 是不同制造商的设备和应用软件在网络中进行通信的标准,此模型已经成为计算机间和网络间进行通信的主要结构模型, 目前使用的大多数网络通信协议的结构都是基于 OSI 模型的。OSI 包括体系结构、服务定义和协议...
  • 以太网帧与ARP协议分析

    千次阅读 2019-12-04 09:22:01
    分析以太网帧,MAC地址和ARP协议 二、实验环境 与因特网连接的计算机网络系统;主机操作系统为windows;使用Wireshark、IE等软件。 三、实验步骤: IP地址用于标识因特网上每台主机,而端口号则用于区别在同一台主机...
  • TCP报文头部选项字段

    千次阅读 2018-01-12 11:36:36
    3.2.2 TCP头部选项 TCP头部的最后一个选项字段(options)是可变长...选项的第一个字段kind说明选项的类型。有的TCP选项没有后面两个字段,仅包含1字节的kind字段。第二个字段length(如果有的话)指定该选项的总长
  • 以太网报文段头部 IP报文段头部 固定部分 可变部分 TCP报文段头部 基于TCP/IP的四层协议的信息封装如下所示: 红色:以太网报文段头部 紫色:IP报文段头部 红色:TCP报文段头部 以太网报文段头部 在...
  • 目录一、以太网二、网络模型三、以太网数据包格式以太网帧格式三、TCP/IP协议簇1、IP协议2、UDP协议 因为没有做过以太网的项目,也没有进行过以太网通信测试,本片博客仅仅是对以太网协议极小一部分的学习了解。如有...
  • Ethernet frame图1以太网头部由三个字段组成:DMAC:表示目的... 1500时,代表该数据帧的类型(比如上层协议类型)常见的协议类型有:0X0800 IP数据包0X0806 ARP请求/应答报文0X8035 RARP请求/应答报文。当LENGTH/TYPE...
  • 以太类型字段中值为0x0800,表示该帧封装了IP 数据报;以及MAC 地址分配的相关信息。 2)分析以太帧结构 将计算机联入网络,打开Wireshark 俘获分组。从本机向192.168.43.53发送ping报文。如下图所示。 回答下列问题...
  • ARP协议报文详解

    千次阅读 2019-01-24 17:52:00
    ARP协议定义  ARP(Address Resolution Protocol)地址解析协议,根据...在通过以太网发送IP数据包时,需要封装第三层(32位IP地址)和第二层(48位MAC地址)的报头,由于发送数据包时,只知道目标IP地址,不知道...
  • 3.IP报文结构分析 (1)分析俘获的分组 打开踪迹文件,对其源地址进行选择,根据源地址作为过滤条件,获得与之相关的分组。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 21,585
精华内容 8,634
关键字:

以太网报文协议类型字段