网络协议总结

身不饥寒，天未尝负我；学无长进，我何以对天。

壹-链路层

1、ARP协议

简介：链路层之间的通讯只需关注双方（任意网段的双方均可而非限定同一网段内的双方）的MAC地址即可无需IP信息，但网络的设计（跨网段通信由网关转发数据包）使得主机只需要关注同一网段内主机的MAC即可，无需关注其它网段内主机的MAC信息。【为了链路层与网络层之间能关联起来，设计终端IP-MAC的映射关系。如果每次通过ARP请求的方式来获取映射关系效率较慢，便设计ARP高速缓冲表以供快速查询映射关系，查询不到再通过ARP请求。】【由于ARP是二层协议，因此接收者并不会区分网段，所以同VLAN下2网段的主机可以发送ARP询问3网段主机的MAC信息（实测可行）。但二层报文一律不能够跨越三层路由进而进行转发。】
ARP表项学习触发时机：（1）自己不知道向别人询问时，根据别人的回答对自己的arp表项进行学习维护（发送请求并收到响应时，学习响应arp中的源ip-mac）；（2）别人不知道向自己询问时，回答并根据别人的提问内容学习维护自己的arp表项（接收请求且target ip匹配自己的ip时，则响应请求并学习请求arp中的源ip-mac）；（3）一个陌生人发来询问或回答时，不予理睬（收到请求但target ip不匹配自己的ip时，arp包直接被丢弃不进行arp源ip-mac学习）。【华为交换机严格ARP学习只有符合(1)中的触发时机时才会学习ARP表项】
动态ARP老化参数：老化超时时间、老化探测次数。（设备上动态ARP表项到达老化超时时间后，设备会发送老化探测报文（即ARP请求报文），如果能收到ARP应答报文，则更新该动态ARP表项，本次老化探测结束；如果超过设置的老化探测次数后仍没有收到ARP应答报文，则删除该动态ARP表项，本次老化探测结束。）【老化探测时的ARP请求报文二层的目的MAC地址是单播而非常规ARP请求中的广播地址。】
ARP种类：普通ARP、免费ARP、翻转ARP(RARP-老版DHCP)、逆向ARP(IARP)、代理ARP（类似于ARP欺骗，需要交换机设备支持）。
正常ARP、免费ARP、IP探测ARP的区别：三者所使用的数据包格式基本上是相同的，区别在于（1）免费ARP中所询问的目标IP地址是它自身，而正常ARP中所询问的目标IP地址是同网段的其它IP主机。（2）免费ARP的目的是为了在自己的IP-MAC对应关系发生变化的时候及时通知其它主机更新其ARP缓冲中已保留的旧的IP-MAC对应关系。（3）IP探测ARP报文的target ip是自己，sender mac是0。该报文的目的是为了在初次使用ip时首先探测网络中是否存在同样的ip，若此时收到响应则电脑会弹出ip冲突的提示。

（ARP消息中Sender和Target的设置均根据当前场景下已知信息进行维护），见下图

貳-网络层

1、IP报文

分片过程：（1）将大数据包分成符合最大传输的小数据包（2）将各小数据包分别添加对应的IP包头（3）各包头中会发生变动的字段Total Length、Identification、Flags、offset，其中Identification总是相等的。（主机每发送一个包标识值加1，而同一包被分片之后的各包的标识值却是相等的）注意如下：
TCP传递下来的包通常不需要进行分片，因为在TCP处的MSS就已经保障了封装的包大小不会超过传输上限；而UDP传递下来的包则可能会发生IP包分片的效果，如超大的ICMP负载报文就可以看到分片效果。（ICMP回应包将携带ICMP请求包所负载的数据，如abcd...）
超大ICMP包分片wireshar分析中发现：分成4个分片的IP包，只有最后一个在wireshark中显示的是ICMP协议，前3个包都是IP()/data，实际上只有第一个包里边的data才携带了ICMP包头的消息，剩下的都是数据。至于为什么wireshark最后一个包显示ICMP包头是因为wireshark对所有的包进行了重组之后统一将ICMP包头消息添加显示在了最后一个包上面。（个人觉得这样容易误导使用者，建议在第一个分包处进行ICMP包头信息的显示）
分片过程发生在网络层，因为网络层收到上面发下来的包由其直接分片然后进行包头封装这个过程会很便利。而如果这个过程交给链路层来做的话，那么链路层分包后还需要将各IP包头所对应的字段进行修改，这个过程对于链路层来说会较为麻烦。
TTL（Time to Live）存活时间：限制数据包在网络中被路由转发的最大次数，通常也相当于数据包经过的路由器数量。【但在二层网络中传输时该值的大小并不会发生变化，因为此过程中只是发生了二层MAC转发并没有发生三层IP转发即路由转发】
Identification标识：主机每发出一个IP包，该值将加1。此字段存在的意义仅在IP分片的时候才有作用，其它时候并无太大意义。【它同ICMP报文中的Identifier字段的意义是不一样的】

2、ICMP协议

ICMP报文通用格式中的Type+Code字段的每种组合均代表一个ICMP类别，而每种类别的ICMP报文格式又都有自己的特点。例如，ICMP Echo回显类别中的Identifier字段的作用是为了一一对应请求包/响应包；ICMP目的不可达类别中会携带未送达报文的IP头+部分负载数据。
常用报文类别：Echo回显(ping)、目的不可达、重定向、超时、参数异常、源端关闭。其中除了Echo回显以外，其余几乎均会携带问题报文的IP头+8/64字节上层协议的部分数据（实测不止64字节），部分消息还会额外携带一个对应消息类型的关键字段，如重定向字段 Gateway Internet Address、参数问题字段 Pointer。
重定向：在特定的情况下，当路由器检测到一台机器使用非优化路由的时候，它会向该主机发送一个ICMP重定向报文，请求主机改变路由。如，当路由器从某个接口收到数据还需要从相同接口转发该数据时；当路由器从某个接口到发往远程网络的数据时发现源ip地址与下一跳属于同一网段时。
超时：即在报文转发过程中TTL存活时间变为零时，网络设备会向包的发起者发送ICMP超时报文。
参数异常：报文字段的值有错误。
源端关闭：用于表示对方或中途的服务器繁忙无法回应时，网络设备发送ICMP源端被关闭消息给该目的主机。如，当网络设备没有足够的缓存空间存储到某个目的主机的报文时，这些报文会被该设备丢弃；当到达某一个主机的数据包过快来不及被主机处理，则该主机也可以发送ICMP源端被关闭消息以便降低数据包速率。

叁-传输层

1、TCP三次连接和四次挥手

总结：

三次握手阶段确立的事情：双发初次发包时携带的seq号即ISN（在wireshark中显示的相对号均为1，实际值并非1）、初次的窗口大小、窗口因子、MSS每个包最大大小。
三次握手与四次挥手都是基于一问一必答互相各问一次的机制，只不过握手2阶段是挥手2、3阶段的整合而已。
而为什么客户端问完服务器（1问答），服务器又问一次客户端呢（2问答）？这是为了检验客户端是否确实是要进行连接或是断开的操作，而不是客户端随意或是不经意的一次操作。（因为这种操作对于客户端来说影响不大，但是对于服务器来说，这种行为是要进行内存划分与回收的操作的，很容易造成内存不足服务器卡死，传输数据失败等问题）
为什么挥手2阶段发生之后需要等待一段时间之后才会发起3阶段的报文？因为1阶段仅仅说明客户端的发送窗口没有数据可发，但是他的接收窗口还在和服务器的发送窗口进行着传输。而当服务器的数据发送完成之后，服务器才会进行3阶段的报文，进行最终的关闭操作。【注意观察4次挥手图片中2次数据传输中的箭头】
为何4阶段发生之后，客户端需要等待2MSL的时长之后才进行关闭操作？假如客户端发完4阶段的包之后就进行关闭操作，那么当4号包丢失之后，服务器就会进行重传操作，但是客户端的连接已经关闭对应的缓冲区也已释放，故这个包并不会得到客户端的回复，于是在经历数次重传失败之后，服务器只能依托keep-active来进行关闭操作，故可知整个过程会使得服务器的缓冲区长时间不能被回收。而在等待2MSL的时长里，如果真有服务器的重传包那么肯定已经过来了，此时再进行回复之后客户端再次开启2MSL的计时等待。如果没包过来，默认服务器已经收到并已关闭连接，那么客户端也就开始关闭连接；而实际上，服务器可能就是因为网络极差或是突然断网的原因导致没有收到包或是重传包没过来，导致要进行上述的keep-alive包的过程。因此4次挥手的完整过程也只是在网络条件理想的情况下进行交互的过程，故理想状态下服务器的关闭要比客户端要早。当然若真的有一种方案可以解决极差网络下的握手挥手问题，我觉得这又回到了两军对阵的问题上。（任何网络协议的过程都是以网络情况理想为前提的，当然也会有一种网络理想之外的万能的解决办法，即keep-active保活检测。）

2、TCP滑动窗口

当TCP堆栈接收到数据的时候，生成一个确认信息并以回复的方式发送，但是放置在接收端缓存中的数据并不总是立即被处理。当服务器忙于处理从多个客户端接收的报文，服务器很有可能因为清理缓存而变得缓慢，无法腾出空间接收新的数据，如果没有流控，则可能会造成丢包和数据损坏。好在，接收窗口所设定的速率无法使服务器正常处理数据时，能够调整接收窗口大小。通过减小返回给发送端的ACK报文的TCP头窗口大小值来实现。
服务端发送零窗口，当客户端接收到此报文时，它会暂停所有数据传输，但会保持与服务器的连接以传输探测（keep-alive）报文。探测报文在客户端以稳定间隙发送，以查看服务器接收窗口状态。一旦服务器能够再次处理数据，将会返回非零值窗口大小，传输会恢复。
滑动窗口直接与服务器无法接收和处理报文有关，任何窗口大小的缩小以及零值都是服务器问题的直接结果。

（猜测：接收/发送窗口和接收/发送缓冲区大小不一致，窗口值显示的是当前缓冲区的可用大小。）

3、包重传机制。

延迟重传：发送方发出包后，经过RTO（通过多个包往返时间计算出来的一个平均时间，RTO是包重传延时计时器的计量单位）之后依旧没有收到来自接收方的ACK确认包，就会触发重传。这种重传接收端并不清楚发生了什么事。
快速重传：发送方发出1、2、3个包，而接收方收到1、3个包，此时接收方因为没有收到预期顺序的包而触发重复ACK，当接收端收到几个同样的重复ACK包之后，就会触发发送方的重传。此时将暂停其它数据包的发送直到重传包被再次发送出去才解除暂停，这种重传由接收端参与并触发。【重复ACK是指在接收方收到乱序报文时，所发出的一类TCP报文。TCP使用报文头的序列号和确认号以有效保证数据按照发送的顺序接收和重组。】
为什么是收到3个重复ACK确认包时才会触发快速重传？快速重传是为了重传丢失的包而不是乱序的包，而乱序包通常混乱的距离不会太远，因此为了避免乱序包误触发快速重传，规定当收到3个同一个包的ACK确认包时才触发快速重传。
快速重传又分为：普通重传和SACK重传。如，发送1-10个包，其中只有3、6、9号包丢失，那么（1）普通重传：接收方将3号包的3个重复ACK发给发送方，发送方会将从3号包开始的8个包再次依照PSH_ACK和ACK的常规数据传输交互方式进行重传（2）SACK重传：接收方会将3个SACK的包发给发送方(每个SACK包中将记录自己这边已经收到的包)，此时发送方对丢包情况了如指掌，此时就只需要将缺少的3、6、9号包依次发送即可。

（数据包第一次重传的延时等待是一个RTO，随后每次重传的延时等待将会随指数增长。Win的重传上限是5次，Linux是15次。若达到一定次数还没有成功时则本地放弃并发送一个复位信号。）

4、TCP中Flag标志含义：

PSH标志：让接收方尽快将缓存区中的内容交付给接收应用进程，而不再等待整个缓存区都填满了后再向上交付。（如，一个较大的http响应报文被拆分成3个tcp包进行传输，那么这3个tcp中的前2个的flag都是ack，只有第3个才是psh+ack；若一个的http请求报文较小，那么这个报文仅由一个tcp包进行传输即可，此时它的flag就是psh+ack。由此可知，psh标识也意味着一个阶段的完成。猜测：wireshark应该就是根据tcp的psh来分析哪些tcp包可以被重组为一个完成的http报文。）

5、网络慢速高延时分析：主要观察包与上一个包之间的相对时间。（1）若TCP三次握手过程中收到的SYN/ACK报文的时间较长，则应该是线路延迟（因为3次握手过程所花费的时间很短，不会存在客户端延迟问题）；（2）若应用层发出应用请求包的时间较长，则应该是客户端延迟（因为客户端发起的应用层请求通常在握手完成之后立马就会发出，不应该会等待）；（3）若收到的应用层响应包响应时间较长，则在排除线路延迟的情况下那么就应该是服务器延迟（通常是由于服务端压力过大导致请求处理繁忙或服务端程序设计存在问题）。

6、杂项

TCP建立连接之时（即三次握手阶段），双方会互相协商MSS的值（此值仅表明发送报文时该分段的最大字节值）、以及各自的最大窗口值（窗口值可能会不同，取决于各自的TCP情况）。之后在互相传输数据的过程中，发送方会根据网络的拥塞情况而动态的调整其传输的数据，但其值总不会超过接收方的接受窗口的值。
客户端与服务器各自维护一个TCP缓冲池，当他们各自向对方发送应用层包时，其Seq号是以各自缓冲池的情况顺序进行的。通常情况下，各自的TCP确认包的Seq号是维持在各自Next Seq的值上，它的存在并不会改变应用包的Seq序列号的顺序。
在用Socket编程时，UDP协议要求包小于64K。TCP没有限定，TCP包头中就没有“包长度”字段，而完全依靠IP层去处理分帧。这就是为什么TCP常常被称作一种“流协议”的原因，开发者在使用TCP服务的时候，不必去关心数据包的大小，只需将SOCKET看作一条数据流的入口，往里面放数据就是了，TCP协议本身会进行拥塞/流量控制。（不过鉴于Internet(非局域网)上的标准MTU值为576字节，所以建议在进行Internet的UDP编程时，最好将UDP的数据长度控制在548字节 (576-8-20)以内。）
当客户端收到来自服务器的包，但是在收到之后的近100毫秒内客户端没有发往服务器的包，则客户端会专门发送一个TCP的确认包。通常在收到包之后的近100毫秒内客户端有发往服务器的应用包，则客户端的ACK确认数据就包含在应用包中发给了服务器。
TCP存活包keepalive探测：存活时长（7200秒）、探测间隔（75秒）、存活重试次数（9次）【值可手动更改】。TCP协议自带的该特性基本没用，故默认处于关闭状态。一般见到的Keepalived包应该都是应用层程序触发实现的。

肆-应用层

1、DHCP协议（UDP）【同类型协议BOOTP（UDP），但已被DHCP取代】

DHCP客户端与服务端进行通信时，客户端发包使用的源端口总是68（bootpc），服务端总是67（bootps）。
DHCP应用层的报文类型只分两种：客户端请求、服务端回应。报文格式总是分为两部分：通用格式、Option格式。其中option格式的起始option id总是53（代表DHCP消息类型），结尾option id总是255（代表option结束字段）。
报文通用格式中的Transaction ID用来标识客户端与服务端在发起会话过程中的所传输的包（如discover四过程中的包的id都是相同的。renew两过程中包的id是相同的）。
报文通用格式中四个IP地址的区别：Client IP address【表示客户端在发包之前的地址。在discovery阶段，客户端还未拥有ip故为0.0.0.0；在renew/release阶段，客户端已拥有ip故为当前ip地址。】、Your (client) IP address【表示服务器分配的地址。在discovery/renew阶段，由服务端发往的offer/ack报文中会被设置。】、Next server IP address【表示DHCP服务器的地址，告知客户端向这个服务器进行ip信息的请求。在discovery/renew阶段，由服务端发往的offer/ack报文中会被设置。】、Relay agent IP address【表示DHCP中继地址。只有当DHCP报文经过中继设备时，才会由DHCP中继进行该字段值的设置，否则默认为0.0.0.0。】（DHCP服务器会根据此中继地址来选择对应网段的DHCP池，从而进行ip信息的分配。）
IP租约相关。在offer/ack报文中会携带：租约总时长、续租时间点（在总时长的50%时发起续租请求）、重绑定时间点（若续租失败，则在总时长的87.5%时重新开始discovery四过程阶段）。
若DHCP客户端与服务端此前已有交互，那么在客户端与服务端处双方各自会留存一份ip使用记录（不管上次是否通过release释放）。这样当客户端下次再次发起ip请求时（不管是续租请求还是发现请求），客户端会主动再其option字段中使用Option: (50) Requested IP Address来再次使用之前的ip地址；或者客户端本地已无此记录但是服务器还存在，那么服务器应该还会为此客户端分配此ip地址。
discovery四过程中，客户端2次发出包的目的mac总是ff、源ip总是0.0.0.0、目的ip总是255.255.255.255，服务端2次发出包的目的mac和目的ip总是客户端实际的mac和由服务器分配给它但未使用的ip地址。【猜测：服务端发出的目的ip似乎并无意义，主要还是通过目的mac通过二层传输将包转送给目的客户端。而无ip的客户端在收到这个带目的ip的报文之后会特殊允许通过，然后客户端才能拥有ip。费解：客户端没有ip但却可以通过UDP的应用层进行通信？】

2、DNS协议（UDP/TCP）

DNS服务支持UDP和TCP，监听于53号端口。DNS客户端域名查询时通过UDP进行数据传输，当DNS主备服务器进行区域传送时通过TCP进行数据传输。【通过dig +tcp www.baidu.com可以强制DNS查询使用TCP进行数据传输】
DNS通用报文中Questions【请求查询的域名数量】、Answer RRs【响应回答的数量】、Authority RRs【权威记录数量】、Additional RRs【附加记录数量】，这些值标明了可选报文部分的大致结构。其中权威记录和附加记录通常在查询域名服务类似baidu.com时，其中的块才会出现权威块列出了查询到的NS记录，附加块将这些NS记录进行了A解析。（dig baidu.com这条命令第一次使用时才会出现权威附加记录，否则得等DNS缓冲记录老化之后再次使用才能出现）（猜测：是否可以通过一个查询报文查询多条域名记录，此时Questions就不再是常见的1了）
通用报文Flag字段中RD（Recursion Desired）和RA（Recursion Available）分别表示：客户端期望的查询方式、服务端实际所使用的查询方式。【递归/迭代】
响应包中可选报文中Queries和Answers块中Name字段的字节大小需要注意。Queries中的name字段是将实际域名通过编码为label序列后的值，这些值的开头会记录这个域名被编码的长度；而Answers中name字段代表的应该是对应Queries中的name值的一个索引，实际并不存储域名本身的值（这也就是为什么响应回答报文中会包含查询请求报文中的内容）。
域名查询时机：本机的dns缓冲池-->本机hosts表-->向配置的所有dns服务器发出请求
DNS查询分为两种：递归查询和迭代查询。递归查询：发出 DNS 请求后，要求对方查好后直接给出最终结果。迭代查询：发出 DNS 请求后，对方如果不知道这个域名的 IP 是什么，会告诉我有可能知道这件事的机器的 IP，我自己再去问有可能知道的机器，不断重复直到问到结果。

3、HTTP协议（TCP）

应用层HTTP的报文字段同应用层的其它协议有所不同（如DNS、DHCP等），它传递给传输层作为Payload中的数据格式是：key:value,[key:value]，而其它协议则通常都是：value,[value]。【而在wireshark中看到的效果却和其它应用层协议无区别，这是由于wireshark针对性解析的原因。】
TCP连接断开与HTTP请求响应的关系：在HTTP/1.0中，客户端建立一个tcp连接并发送http请求，当http响应被服务端发送并确保客户端已ack的情况下，服务端则主动开始tcp四次挥手进行tcp断开操作；（这样每次请求都需要建立新的tcp连接代价较大）在HTTP/1.1（该版本最流行）中，支持持久连接并默认开启字段Connection，这样在完成一个http请求之后建立的tcp连接通道并不会马上断开短时间（打开一个包含很多的js、css、图片等文件的页面，那么这些文件就会被浏览器立马请求通过这条已建立的tcp通道进行数据传输；而如果页面已加载完成这时候等了几秒中之后又去访问页面上的一个资源时，这时候就可能会建立新的tcp通道了）内可以重复被使用。
HTTP/2多路传输：一个TCP连接中可以依次发送多个HTTP请求，依次收到多个HTTP响应，而非一问一答。但在HTTP/1.1中默认则是通过一问一答的方式，支持Pipelining但效果不佳。
浏览器对同一 Host 建立TCP连接的数量限制。当一个页面中包含了1000张图片要去获取/请求，（1）如果是HTTP/1.0的方式，则需要建立1000个tcp连接；（2）如果是HTTP/1.1的方式，则建立一个tcp连接然后顺序下载速度较慢也不妥，所以Chrome浏览器（其余浏览器各有所区别）允许对同一个Host最多建立6条TCP连接。如果6条通道都被使用那么其它请求就需要等待了；（3）如果是HTTP/2的方式，则应该会使用多TCP通道及多路传输。（但是现实中HTTP/2都是在HTTPS上实现的，因此对于HTTP的页面多资源请求就只能使用HTTP/1.1）

4、SSL/TLS协议（TCP）

通道建立流程：（1）Client Hello（2）Server Hello、Certificate、Server Key Exchange、ServerHello Done（3）Client Key Exchange、Change Cipher Spec、Finish（Encrypted）（4）New Session Ticket、Change Cipher Spec、Finish（Encrypted）（5）通道建立完成，开始消息加密传输。【此处双方只交互了4次便完成了通道的建立，实际中交互次数并不确定，可能是4次也可能是将步骤二拆开变成5次。但总体上而言，其过程就是：“Hello阶段协商加密套件，Key Exchange阶段交换加密套件所需要的基础参数，Finish阶段结束通道建立交互”。Certificate内容的作用：身份认证、RSA密钥交换】
TLS历史版本：SSL主要由网景公司设计并维护，SSL3.0之后该公司停止维护，随后便主要由IETF将SSL3.0标准化为TLS1.0，并持续维护了TLS1.1、TLS1.2、TLS1.3这些版本。
解密TLS数据包的方式有2种：（1）密钥交换算法选择RSA，然后提取服务器的私钥，将私钥导入Wireshark，通过Wireshark解密密钥交换过程中传递的预主密钥，再结合之前的客户端和服务器随机数生成主密钥，进一步生成加密密钥，即可解密后续抓取到的加密报文。（2）直接从客户端提取预主密钥，结合客户端和服务器随机数生成加密密钥，实现对加密报文的解密。【这两种方式的目的都是为了获取预主密钥，而该密钥的获取取决于TLS协商阶段选择的密钥交换算法是RSA还是DH。实际上通常都是DH也就是使用第二种方法wireshark才能成功解密数据。】
TLS协议构成：由记录协议和握手协议叠加而成。低层的记录协议负责确定上层的握手协议数据的封装格式，其格式总是固定的类型、版本、长度、握手协议数据；上层的握手协议则负责加密通道协商及其它应用层数据的加密操作，其格式多种多样，不同的握手协议格式基本大不相同。【由于记录协议具有固定格式的特性，故通常一个TLS数据包中可以支持携带多个握手协议的数据。】

5、SSH协议（TCP）

SSH协议基本框架：传输协议（第一阶段明文通信。提供了服务器认证、数据加密、数据压缩功能。）、用户认证协议（第二阶段密文通信。向服务器提供了客户端用户鉴别功能。）、连接协议（第三阶段密文通信。提供了用途广泛的各种通道，如，安全交互式会话外壳、隧道技术转发专有 TCP/IP 端口和 X11 连接。）。【wireshark只能看到第一阶段传输的数据包详情，关于SSH解密数据包解析目前wireshark暂不支持，目前只能通过重新改写sshd源码的方式更近一步了解其通信过程】
传输协议部分第一阶段通信建立流程：（1）Client：Protocol（2）Server：Protocol（3）Client：Key Exchange Init（4）Server：Key Exchange Init（5）Client：EC DH Key Exchange Init（6）Server：EC DH Key Exchange Reply，New Keys（7）Client：New Keys（8）传输层协议完成，开始后续交互【此部分同TLS通道建立的过程很相似，总体上也是：“打招呼、交换加密套件、根据确定的加密套件交换所需的基础参数、结束”，该过程主要是确定了对称会话密钥，以加密后续传输的认证、数据报文。步骤6中携带的服务端公钥的作用：身份认证、RSA密钥交换】
身份验证方式：密码（Password）、公钥私钥（Publickey）、交互式（keyboard-interactive）。其中密码和公钥私钥登录的方式通过SSH协议框架第二阶段的用户认证协议进行验证，交互式登录则属于过SSH协议框架第三阶段的连接协议进行验证（具体情况不明）。【猜测：密码认证时，客户端使用传输层阶段得到的服务器公钥对要验证的账户及密码进行加密，然后发送给服务端由其使用私钥解密验证；公私钥认证时才会用到客户端公私钥对，客户端用私钥加密一段信息然后发给服务端，服务端用得到的客户端公钥进行解密由此验证了客户端可信任。】

6、FTP协议（TCP）

FTP工作原理：在两台通信的主机之间建立两条信息流，一条是控制流，用于传送控制信息（命令和响应），另一条是数据流，用于数据传送；其中控制流总是由客户端的随机端口向服务端的TCP/21号端口发起的连接，而数据流在FTP主动模式PORT下时，是由服务端的TCP/20号端口向客户端协商的随机端口发起的连接，在FTP被动模式PASV下时，是由客户端的随机端口向服务端协商的随机端口发起的连接。【被动模式是为了解决在主动模式下服务端无法与NAT后面的客户端建立连接而被设计】
数据流的两种传输方式：文本传输方式、二进制传输方式。当使用文本方式传输文件时，ftp服务端通常会自动地调整文件的内容以便于把文件解释成适合另外那台计算机存储文本文件的格式；当使用二进制方式传输文件时，文件的内容都是原封不动一个字节都没有被改变过。因此，对于文本文件的传输，使用文本传输方式可以免去windows和linux回车符转换的问题，而对于非文本文件的传输，则最好使用二进制传输方式，否则可能会造成文件的传输错误。建议统一使用二进制方式进行传输，这样可以避免很多问题。
FTP应用行为分析：首先建立一条控制流TCP连接（来自服务端的欢迎消息、登录认证交互、系统型号特性应答）。当客户端发送PWD、CWD、PORT、PASV等控制指令时，不会产生数据流通道的建立；当客户端发送LIST控制指令请求目录列表时，会触发数据流通道的建立，目录列表传输之后数据流通道由服务端主动发起4次挥手关闭；当客户端需要进行文件下载时，会重新建立一条控制流然后发送RETR下载指令，触发新的数据流通道建立，当文件下载完成之后这条新建的控制流和数据流通道将会被关闭（此行为来自对FileZilla客户端下载文件的观察，但实际上还是遵循控制流发送下载指令数据流传输文件的规则）。
报文类型分为两类：请求（Request cmd: Request arg）、响应（Response code: Response arg）。其中请求的cmd是4字节响应的code是3字节，cmd/code与arg之间由16进制20分割，结尾是16进制的0d0a收尾。

（主动/被动模式下的请求/响应报文中会携带待连接主机的ip-port信息），见下图

7、Kerberos协议（TCP）

Kerberos协议是一个专注于验证通信双方身份的网络认证协议，不同于其他网络安全协议的保证整个通信过程的传输安全，kerberos侧重于通信前双方身份的认定工作，帮助客户端和服务端在一个不安全的网络中完成一次安全的身份认证继而进行安全的通信。
关键点：该协议借助“可信赖的第三方”来达到客户端和服务端双方身份鉴别的工作（通信中需要加密的部分数据均是使用对称加密实现，另一种双方身份互相鉴别的方式是通过客户端和服务端相互验证对方的公钥证书实现），“可信赖的第三方”别称 KDC密钥分发中心=AS认证服务器+TGS票据授权服务器+密钥数据库（一般是AD活动目录）。其中密钥数据库中存储着每个网络实体（AD中的网络实体是指登录用户账户、机器账户，机器账户即加域的计算机名后面加一个\(符，如DC01\)，机器账户的初始密码是由120个随机字符组成。）独有的密钥，这个密钥只有网络实体自己和KDC知道，这个密钥被用来对称加密网络实体与KDC之间的会话内容，而网络实体之间的会话内容则通过由KDC临时随机分配的会话密钥进行对称加密。详见
工作原理简述：（1）用户输入账户和密码到客户端程序，客户端将密码通过单向函数进行哈希转化为“用户密钥”。（2）客户端向AS认证服务器发起AS-REQ请求【请求中包含用户登录账户等信息，若KDC启用了预身份认证则此处也会包含“用户密码”的信息】（3）AS认证服务器给客户端返回AS-REP响应【响应中包含通过“TGS密钥(即KDC内置的Krbtgt用户)”加密的“客户端-TGS会话密钥”即TGT金票据、通过“用户密钥”加密的 “客户端-TGS会话密钥”】（4）客户端向TGS票据授权服务器发起TGS-REQ请求【请求中包含通过“TGS密钥”加密的TGT票据、通过“客户端-TGS会话密钥”加密的时间戳】（5）TGS票据授权服务器给客户端返回TGS-REP响应【响应中包含通过“客户端-TGS会话密钥”加密的“客户端-服务器会话密钥”、通过“服务器密钥（即机器账户的密钥）”加密的“客户端-服务器会话密钥”即SS银票据】（6）客户端向提供service server发起认证请求（该请求通常被夹带在应用服务通过kerberos认证的认证请求当中，不同于上面的AS-REQ/TGS-REQ这种单独的请求）【请求中包含通过“服务器密钥（即机器账户的密钥）”加密的“客户端-服务器会话密钥”、通过“客户端-服务器会话密钥”加密的时间戳】（7）service server解密得到“客户端-服务器会话密钥”然后交互返回认证响应以完成认证，最终客户端正常连接应用服务。举例说明：抓包分析SMB登录时发现，先是通过SMB报文协商交互，然后开始进行kerberos交互客户端得到TGT金票据和SS银票据，然后继续开始SMB交互，此时会看到SMB-Session Setup Request报文中会包含SS银票据相关的信息，最后SMB交互完毕。
常见的网络服务认证均是基于密码进行的认证交互，而Kerberos则是是基于票据。总结以上认证流程无非就是：客户端首先向KDC-AS发起请求获得TGT金票据，然后客户端又拿着TGT票据向KDC-TGS申请SS银票据，最后客户端拿着SS票据向service server进行认证获得服务的访问权。因此，如果我们获得了Krbtgt用户的HTML密钥，就可以伪造TGT金票据；如果获得了机器账户的密钥，就可以伪造SS银票据。【使用一张TGT金票据可以申请到好多SS银票据，继而获得对各应用服务的访问权限。】
使用 Windows 域时，所有凭据都存储在DC域控制器中，每当用户尝试使用域凭据对服务进行身份验证时，服务都将请求DC域控制器来验证该用户身份是否正确。此时可以使用两种协议在 Windows 域中进行网络身份认证：（1）Kerberos: 任一最新版本的 Windows 都能使用，这是任意最新域中的默认协议。（2）NetNTLM: 为兼容性目的而保留的遗留身份验证协议。

NetNTLM网络认证，见下图

Kerberos网络认证，见下图

Kerberos 流程数据包，见下图

8、NetBIOS协议（API）

netbios是一种会话层服务，而不是网络协议，属于一种应用层程序接口。它旨在让处在同一局域网下的不同计算机上运行的不同程序可以共处于同一个会话环境中，进而使得程序之间可以随意的传递数据信息。不同程序在进行网络上信息资源的获取和传输时只需调用NETBIOS提供的接口即可，而不必让程序员去深入理解各种网络套接字函数的用法之后才能进行工作，这为程序员提供了很大的便利。【NetBIOS上层接口对相关网络信息的可用与否实际上和底层相关的服务是否正常运行有关，当服务承载在TCP/IP上时，底层则运行着名称解析服务、数据报服务、会话服务这三个服务以随时为上层提供服务。】
NetBIOS会话层接口服务可以运行在tcp/ip ipx/spx netbios frame（非路由网络协议，类似于一种帧协议）这些网络传输通讯协议之上，现代操作系统通常运行在tcp/ip的网络传输协议之上。运行在TCP/IP网络上时，相应的三个服务使用的端口分别为 UDP137（名称解析服务：主要作用是在局域网中提供计算机的名称或IP地址查询服务）、UDP138（无连接的数据报服务：主要作用是提供NetBIOS环境下的计算机名浏览功能）、TCP139/445（有连接的会话服务：用于处理NBT会话，NBT会话用于包含SMB会话的轻量级协议，其主要作用是提供文件和打印机共享功能【139端口似乎已被445端口替换，实测共享打印机和共享文件的数据包交互都是使用TCP445端口的SMB协议。】）。
NETBIOS是可路由的服务，只是在默认情况下只在同一网段下的终端才广播注册互相发现对方。如果要实现不同网段的主机名服务，一般需要设置WINS来解析。【但通过nbtscan x.x.x.x 实测发现，当不在同一网段时，依旧可以指定查询指定 ip 地址的NBS名称。】

NetBIOS网络架构图，见下图

NetBIOS 名称服务/数据报服务数据包，见下图

9、SMB/CIFS协议（TCP）

SMB/CIFS属于一种应用层的网络协议，主要功能是使网络上的机器能够共享计算机文件、打印机、串行端口和通讯等资源。SMB可以以不同方式运行在会话层或者更低的网络层之上：（1）运行于NetBIOS 之上（而NetBIOS本身则运行在NetBEUI、IPX/SPX或TCP/IP协议上）（2）直接运行在 TCP445端口
工作原理：（1）版本协商【版本主要分为SMB1、SMB2、SMB3，版本1-2使用较多】（2）认证协商【认证方式主要支持NetNTLM、Kerberos】（3）认证交互（4）资源访问【文件读写类似于编程一样，需要经过文件连接、信息获取、权限判断等繁琐的操作，而每一个操作又对应着数个网络请求包的发起/响应，过程相当繁琐。】
应用范围：（1）Windows下SMB/CIFS是适用于Windows服务器和客端的标准文件和打印机共享系统，故Windows系统无需额外安装软件来；（2）Linux下通过Samba软件服务来将Linux文件系统作为CIFS/SMB网络文件进行共享,同时也支持将Linux下的打印机作为CIFS/SMB打印机共享而进行共享。
杂项：（1）文件共享通用连接方式\\ip，但在局域网内，由于NBTBIOS名称解析服务的存在，故也可使用\\MachineName的连接方式。（2）SMB共享对文件的操作与使用FileZilla FTP客户端对文件的操作过程很相似，都是在初次登录打开时产生一次tcp连接（连接包括协商、登录等过程），当点击进入一个目录时又会产生一次tcp连接（连接依旧包括协商、登录等过程）。

文件共享初次连接打开时所产生的包交互过程，见下图

10、RPC协议

rpc协议作用于传输层之上应用层之下，使用的固定端口是tcp135，动态端口50000以上，专门为程序网络接口调用所使用，相当于一个轻量版的http接口。

伍-杂项

技巧：对于各种应用层协议在OSI七层中的对应位置，通过wireshark-统计-协议分级，可以帮助更好的理解。
技巧：当分析一个包含多个TCP会话的应用流程时，可以通过过滤器先筛选出syn相关的包（tcp.flags == 0x002）以确定会话数量（统计-会话-TCP亦可查看），然后依次为不同的会话着不同的颜色，这样就会使得应用行为的先后顺序非常明显。
每一个捕获包的Frame层并非实际存在，它只是由wireshark捕获并添加，物理链路上实际传输的只是Ethernet II层的数据。（Frame层主要记录了数据包被捕获的时间、包大小、以及包的序号这些信息。）
常用文件的文件头（十六进制）：JPEG (jpg) 文件头：FFD8FF、PNG (png) 文件头：89504E47、GIF (gif) 文件头：47494638、XML (xml) 文件头：3C3F786D6C、HTML (html) 文件头：68746D6C3E、Adobe Acrobat (pdf) 文件头：255044462D312E、ZIP Archive (zip) 文件头：504B0304、RAR Archive (rar) 文件头：52617221。【文本文件无文件头直接开始就是数据】
以太帧Ethernet Ⅱ通过Type字段（IP、ARP等）、IP报文通过Protocol字段（TCP、UDP、ICMP、OSPF等）指出它们所携带的上层数据使用了何种协议，以便目的主机知道该将数据部分交给哪个进程进行处理。【猜测：TCP/UDP报文可能也想过使用应用层类型字段的说法，但由于应用层软件太过丰富硬性规定灵活度不高，于是便将这个应用层类型字段以Port的方式替代。】