ARP（Address Resolution Protocol）位址解析協定，将IP位址解析成MAC位址。
IP位址在OSI模型第三層，MAC位址在OSI第二層，彼此不直接通信；
在通過以太網發生IP資料包時，先封裝第三層（32位IP位址）和第二層（48位MAC位址）的報頭；
但由于發送資料包時隻知道目标IP位址，不知道其Mac位址，且不能跨越第二、三層，是以需要使用位址解析協定。
ARP工作流程分請求和響應：
在dos視窗内“ping”某個域名抓取到的包：
IP（Internet Protocol）網際網路協定，主要目的是使得網絡間能夠互相通信，位于OSI第三層，負責跨網絡通信的位址。
當以廣播方式發送資料包的時候，是以MAC位址定位，并且需要電腦在同一子網絡。
當不在同一子網絡就需要路由發送，這時候就需要IP位址來定位。
同樣在dos視窗内“ping”某個域名抓取到的包：
TCP（Transmission Control Protocol）傳輸控制協定，一種面向連接配接、可靠、基于IP的傳輸層協定，主要目的是為資料提供可靠的端到端傳輸。
在OSI模型的第四層工作，能夠處理資料的順序和錯誤恢複，最終保證資料能夠到達其應到達的地方。
1）标志位
SYN： 同步，在建立連接配接時用來同步序号。SYN=1， ACK=0表示一個連接配接請求封包段。SYN=1，ACK=1表示同意建立連接配接。
FIN： 終止，FIN=1時，表明此封包段的發送端的資料已經發送完畢，并要求釋放傳輸連接配接。
ACK： 确認，ACK = 1時代表這是一個确認的TCP包，取值0則不是确認包。
DUP ACK：重複，重複确認封包，有重複封包，一般是是丢包或延遲引起的，從這個封包看應該是丢包了。
URG：緊急，當URG=1時，表示封包段中有緊急資料，應盡快傳送
PSH：推送，當發送端PSH=1時，接收端盡快的傳遞給應用程序
RST：複位，當RST=1時，表明TCP連接配接中出現嚴重差錯，必須釋放連接配接，再重建立立連接配接
2）端口
用戶端與不同伺服器建立連接配接時，源端口和目标端口可不同。
3）TCP三向交握
4）TCP四次揮手
TCP四次斷開，例如關閉頁面的時候就會斷開連接配接。
5）TCP概念
1. 發送視窗
無法簡單的看出發送視窗的大小，發送視窗會由網絡因素決定。發送視窗定義了一次發的位元組，而MSS定義了這些位元組通過多少個包發送。
2. 擁塞視窗（cwnd）
描述源端在擁塞控制情況下一次最多能發送的資料包的數量。
在發送方維護一個虛拟的擁塞視窗，并利用各種算法使它盡可能接近真實的擁塞點。
網絡對發送視窗的限制，就是通過擁塞視窗實作的。
3. 在途位元組數（bytes in flight）
已經發送出去，但尚未被确認的位元組數。
在途位元組數 = Seq + Len - Ack
其中Seq和Len來自上一個資料發送方的包，而Ack來自上一個資料接收方的包。
4. 擁塞點（congestion point）
發生擁塞時候的在途位元組數就是該時刻的網絡擁塞點。
先從Wireshark中找到一連串重傳包中的第一個，再根據該Seq找到原始包最後計算該原始包發送時刻的在途位元組數。
5. 慢啟動
RFC建議初始擁塞視窗發送2、3、或4個MSS，如果發出去的包都能得到确認，則表明還沒到擁塞點，可以收到n個确認增加n個MSS
6. 擁塞避免
慢啟動持續一段時間後，擁塞視窗達到一個較大的值，就得放慢RFC建議在每個往返時間增加1個MSS，比如發了16個MSS全部确認，那麼就增加到17個MSS
7. 逾時重傳
發出去的包在等待一段時間（RTO）後，沒有收到确認，就隻能重傳了
8. 快速重傳（Fast Retransmit）
不以時間驅動，而以資料驅動重傳。如果包沒有連續到達，就ACK最後那個可能被丢了的包，如果發送方連續收到3次相同的ACK，就重傳。
9. SACK（Selective Acknowledgment）
選擇性确認重傳，ACK還是Fast Retransmit的ACK，SACK則是彙報收到的資料，在發送端就可以根據回傳的SACK來知道哪些資料到了，哪些沒有到。
10. 延遲确認（Delayed ACK）
如果收到一個包後暫時沒什麼資料發給對方，那就延遲一段時間再确認。假如這段時間恰好有資料要發送，那資料和确認資訊可以在一個包中發送。
11. LSO
LSO拯救CPU而出的創意，為了緩解CPU的壓力，把它的一部分工作外包給了網卡，比如TCP的分段。
啟用LSO之後，TCP層就可以把大于MSS的資料塊直接傳給網卡，讓網卡負責分段。
比如“Seq=348586，Len=2776”，被網卡分為“Seq=348586，Len=1388”和“Seq=349974，Len=1388”兩個包。
在發送端抓包相當于站在CPU角度，隻看到一個分段前的大包，而接收端就可以看到兩個包。
是以才會出現隻見重傳包，不見原始包的情況。
12. Nagle算法
在發出去的資料還沒有被确認之前，假如又有小資料生成，那就把小資料收集起來，湊滿一個MSS或等收到确認後再發送。
13. Vegas算法
通過監控網絡狀态來調整發包速度。
當網絡狀态良好時，資料包的RTT比較穩定，這時可以增大擁塞視窗；
當網絡開始繁忙時，資料包開始排隊，RTT就會變大，這時就減小擁塞視窗。
6）選項字段
PTR（Pointer Record）：指針記錄，PTR記錄解析IP位址到域名
TTL（Time to live）：
存活時間，限制資料包在網絡中存在的時間，防止資料包不斷的在IP網際網路絡上循環，初始值一般為64，每經過一個路由減去1。
通過TTL過濾營運商劫持包，假的包是搶先應答的，是以和真實包的TTL可能不同（例如ip.ttl == 54）
Seq：資料段的序号，當接收端收到亂序的包，就能根據此序号重新排序，目前Seq等上一個Seq号與長度相加擷取到
Len：資料段的長度，這個長度不包括TCP頭
Ack：确認号，接收方向發送方确認已經收到了哪些位元組
RTT（Round Trip Time）：也就是一個資料包從發出去到回來的時間
RTO（Retransmission TimeOut）：逾時重傳計數器，描述資料包從發送到失效的時間間隔，是判斷資料包丢失與否及網絡是否擁塞的重要參數
MTU（Maximum Transmit Unit）：最大傳輸單元
MSS（Maximum Segment Size）：最長封包段，TCP包所能攜帶的最大資料量，不包含TCP頭和Option。一般為MTU值減去IPv4頭部(至少20位元組)和TCP頭部(至少20位元組)得到。
Win（Window Size）：聲明自己的接收視窗
TCP Window Scale：視窗擴張，放在TCP頭之外的Option，向對方聲明一個shift count，作為2的指數，再乘以TCP定義的接收視窗，得到真正的TCP視窗
DF（Don't fragment）：在網絡層中，如果帶了就丢棄沒帶就分片
MF（More fragments）：0表示最後一個分片，1表示不是最後一片
7）過濾表達式
握手請求被對方拒絕：tcp.flags.reset === 1 && tcp.seq === 1
重傳的握手請求：tcp.flags.syn === 1 && tcp.analysis.retransmission
過濾延遲确認：tcp.analysis.ack_rtt > 0.2 and tcp.len == 0
UDP（User Datagram Protocol）使用者資料報協定，提供面向事務的簡單不可靠資訊傳送服務。
将網絡資料流壓縮成資料包的形式。每一個資料包的前8個位元組儲存標頭資訊，剩餘的包含具體的傳輸資料。
雖然UDP是不可靠的傳輸協定，但它是分發資訊的理想協定，例如在螢幕上報告股票市場、顯示航空資訊；
在路由資訊協定RIP（Routing Information Protocol）中修改路由表、QQ聊天、迅雷、網絡電話等。
TCP的效率不一定比UDP低，隻要視窗足夠大，TCP也可以不受往返時間的限制而源源不斷地傳資料。
1）UDP的優勢
1. UDP 協定的頭長度不到TCP頭的一半，是以同樣大小的包裡UDP攜帶的淨資料比TCP包多，
2. 沒有Seq和Ack等概念，省去了建立連接配接的開銷，DNS解析就使用UDP協定。
2）UDP的劣勢
1. 超過MTU的時候，發送方的網絡層負責分片，接收方收到分片後再組裝起來，這個過程會消耗資源，降低性能。
2. 沒有重傳機制，丢包由應用層處理，某個寫操作有6個包，當有一個丢失的時候，就要将6個包重新發送。
3. 分片機制存在弱點，接收方是根據包中的“More fragments”的flag來判斷是否包已接收完，1表示還有分片，0表示最後一個分片，可以組裝了。
如果持續發送flag為1的UDP，接收方無法組裝，就有可能耗盡記憶體。
ICMP（Internet Control Message Protocol）網際封包控制協定，用于傳輸錯誤報告控制資訊，對網絡安全有極其重要的意義。
例如請求的服務不可用、主機或路由不可達，ICMP協定依靠IP協定來完成任務，是IP協定的一個內建部分。
通常不被使用者網絡程式直接使用，多用于ping和tracert等這樣的診斷程式。
DNS（Domain Name System）域名系統，DNS就是進行域名解析的伺服器。
DNS協定運作在UDP協定之上，端口為53，工作原理如下：
DNS的解析過程：
DNS客戶機向本地域名伺服器A發送查詢，如果A中沒有儲存IP位址記錄，A就會發請求給根域名伺服器B
如果B中也沒有，A就發請求給C，再沒有就發請求給D，然後是E，找到後将位址發給DNS客戶機。
域名解析過程涉及到遞歸查詢和疊代查詢。
客戶機再與Web伺服器連接配接。
HTTP（HyperText Transfer Protocol）超文本傳輸協定，HTTP是一個應用層協定，無狀态，由請求和響應構成，是一個标準的用戶端伺服器模型。
HTTP工作流程如下：
HTTP請求頭域：
Accept
Accpet-Charset
通知伺服器使用者代理支援的字元集及字元集的相對優先順序，“iso-8859-5”
Accept-Encoding
告知伺服器使用者代理支援的内容編碼及優先級順序“gzip,deflate”
Accept-Language
告知伺服器使用者代理能夠處理的自然語言集及優先級，“zh-cn,zh;q=0.7”
Authorization
使用者代理的認證資訊（證書值），“Basic dWVub3NlbjpwYNzd==”
Expect
期望出現的某種特定行為，錯誤時傳回“417 Expectation Failed”，“100-continue”
From
使用者的電子郵箱位址，為了顯示搜尋引擎等使用者代理負責人的聯系方式，“[email protected]”
Host
請求的資源所處的網際網路主機名和端口号，必須包含在請求頭中，“www.hh.com”
If-Match
條件請求，隻有當If-Match字段值與ETag比對才會接受請求，否則傳回“412 Precondition Failed”
If-Modified-Since
若字段值早于資源的更新時間（Last-Modified），資源未更新，傳回“304 Not Modified”
If-None-Match
與If-Match相反
If-Range
字段值和請求資源的ETag或時間一緻時，作為範圍請求處理，反之，傳回全體資源
If-Unmodified-Since
與If-Modified-Since作用相反
Max-Forwards
以十進制整數形式指定可經過的伺服器最大數目。伺服器轉發一次，減少1，當為0就不進行轉發
Proxy-Authorization
接收從代理伺服器發來的認證質詢時，發送此字段，告知伺服器認證所需要的資訊
Range
隻需擷取部分資源的範圍請求，“5001-10000”從5001位元組到10000位元組的資源。
Referer
請求的原始資源的URI，也就是上一頁
TE
用戶端能夠處理響應的傳輸編碼方式及相對優先級，還可指定Trailer字段分塊傳輸編碼的方式。“gzip,deflate;q=0.5”
User-Agent
建立請求的浏覽器和使用者代理名稱等資訊
HTTP應答頭域：
Accpet-Ranges
告知用戶端伺服器是否能處理範圍請求，以指定擷取伺服器端某個部分的資源。“bytes”
Age
源伺服器在多久前建立了響應，字段值機關為秒
ETag
用戶端實體辨別，一種可以将資源以字元串形式做唯一辨別的方式
Location
将響應接收方引導至某個與請求URI位置不同的資源，會配置3xx：Redirection的響應
Proxy-Authenticate
由代理伺服器所要求的認證資訊發送給用戶端
Retry-After
告知用戶端應該在多久（秒數或具體日期）之後再次發送請求，主要配合“503 Service Unavailable”或“3xx Redirect”。
Server
目前伺服器上安裝的HTTP伺服器應用程式的資訊，包括版本号等。“Apache/2.2.6 (Unix) PHP/5.2.5”
Vary
對緩存進行控制，設定“Accept-Language”，如果字段值相同，就從緩存傳回響應。
WWW-Authenticate
HTTP通路認證，告知用戶端适用于通路請求URI所指定資源的認證方案（Basic或Digest）和帶參數提示的質詢（challenge）
HTTP通用頭域：
Cache-Control
操作緩存的工作機制，多個指令用“,”分割，“private,max-age=0,no-cache”
Connection
控制不再轉發給代理的首部字段與管理持久連接配接，“keep-alive”
Date
HTTP封包的日期和時間
Pragema
HTTP1.1之前的遺留字段，作為向後相容定義，隻用在用戶端發送的請求中。“no-cache”
Trailer
說明在封包主體後記錄了哪些首部字段，可應用在分塊編碼傳輸時。在封包最後寫了重要資訊
Transfer-Encoding
傳輸封包主體時采用的編碼方式，分塊傳輸“chunked”
Upgrade
檢測HTTP協定及其他協定是否可使用更高版本進行通信
Via
追蹤用戶端與伺服器之間的請求和響應封包的傳輸路徑，各個代理伺服器會往Via添加自己的伺服器資訊
Warning
告知使用者一些與緩存相關問題的警告
HTTP實體頭域：
Allow
告知用戶端能夠支援Request-URI指定資源的所有HTTP方法，“GET,HEAD”。當不支援，會傳回“405 Method Not Allowed”
Content-Encoding
伺服器對實體的主體部分選用的内容編碼方式，在不丢失内容的前提下進行壓縮。“gzip”
Content-Language
實體主體使用的自然語言（中文或英文等）
Content-Length
主體部分的大小（機關是byte）
Content-Location
給出與封包主體部分相對應的URI，與Location不同
Content-MD5
一串由MD5算法生成的值，目的在于檢查封包主體在傳輸過程中是否保持完整，以及确認傳輸到達
Content-Range
針對範圍請求，作為響應傳回的實體的哪個部分符合範圍請求，機關為byte。“bytes 5001-10000/10000”
Content-Type
實體主體内對象的媒體類型，與Accpet一樣，字段值用type/subtype形式指派。“text/html; charset=UTF-8”
Expires
将資源失效的日期告知用戶端。當首部字段Cache-Control有指定max-age指令時，優先處理max-age指令
Last-Modified
指明資源最終修改時間，一般來說，這個值就是Request-URI指定資源被修改的時間
HTTPS（Hypertext Transfer Protocol over Secure Socket Layer）基于SSL的HTTP協定，HTTP的安全版。
使用端口43，HTTPS協定是由SSL+HTTP協定建構的可進行加密傳輸和身份認證的網絡協定。
1）HTTPS工作流程
2）SSL
SSL（Secure Sockets Layer）安全套接層，TLS（Transport Layer Security）傳輸層安全是其繼任者。
SSL和TLS在傳輸層對網絡連接配接進行加密。
SSL協定分為兩層，SSL記錄協定（SSL Record Protocol）和SSL握手協定（SSL Handshake Protocol）。
SSL記錄協定建立在TCP之上，提供資料封裝、壓縮加密基本功能的支援。
SSL握手協定建立在SSL記錄協定之上，在資料傳輸之前，通信雙方進行身份認證、協商加密算法和交換加密秘鑰等。
SSL工作分為兩個階段，伺服器認證和使用者認證。
SSL協定既用到了公鑰加密（非對稱加密）又用到了對稱加密技術。
3）資料包
用戶端與伺服器之間的通信：
1.用戶端送出請求（Client Hello）
2.伺服器響應（Server Hello）
3）證書資訊
3.密鑰交換
4.應用層資訊通信
使用者可以發送通過TLS層使用RC4的寫執行個體加密過的普通HTTP消息，也可以解密服務端RC4寫執行個體發過來的消息。
此外，TLS層通過計算消息内容的HMAC_MD5哈希值來校驗每一條消息是否被篡改。
參考資料：
<a href="http://download.csdn.net/download/loneleaf1/9730490" target="_blank">Wireshark網絡分析的藝術</a>
<a href="http://download.csdn.net/download/loneleaf1/9730491" target="_blank">Wireshark資料包分析實戰詳解</a>
<a href="https://zhuanlan.zhihu.com/p/21268782" target="_blank">車小胖談網絡：MTU 與 MSS</a>
<a href="http://infotech.blog.51cto.com/391844/123859" target="_blank">MTU & MSS 詳解記錄</a>
<a href="http://blog.csdn.net/peijian1998/article/details/40106965" target="_blank">網絡傳輸分片、MTU、MSS</a>
<a href="http://blog.csdn.net/a19881029/article/details/38091243" target="_blank">了解TCP序列号（Sequence Number）和确認号（Acknowledgment Number）</a>
<a href="http://www.seanyxie.com/wireshark%E6%8A%93%E5%8C%85%E5%9B%BE%E8%A7%A3-tcp%E4%B8%89%E6%AC%A1%E6%8F%A1%E6%89%8B%E5%9B%9B%E6%AC%A1%E6%8C%A5%E6%89%8B%E8%AF%A6%E8%A7%A3/" target="_blank">wireshark抓包圖解 TCP三向交握/四次揮手詳解</a>
<a href="http://coolshell.cn/articles/11609.html" target="_blank">TCP 的那些事兒（下）</a>
<a href="http://blog.163.com/hlz_2599/blog/static/142378474201151933643431/" target="_blank">TCP segment of a reassembled PDU</a>
<a href="http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html" target="_blank">SSL/TLS協定運作機制的概述</a>
<a href="http://joji.me/zh-cn/blog/walkthrough-decrypt-ssl-tls-traffic-https-and-http2-in-wireshark" target="_blank">如何通過Wireshark檢視HTTPS、HTTP/2網絡包（解碼TLS、SSL）</a>
本文轉自 咖啡機（K.F.J） 部落格園部落格，原文連結：http://www.cnblogs.com/strick/p/6262284.html，如需轉載請自行聯系原作者