目錄
一、OSI七層模型
開放系統互連參考模型 (Open System Interconnect 簡稱OSI）是國際標準化組織(ISO)和國際電報電話諮詢委員會(CCITT)聯合制定的開放系統互連參考模型，爲開放式互連信息系統提供了一種功能結構的框架。其目的是爲異種計算機互連提供一個共同的基礎和標準框架，併爲保持相關標準的一致性和兼容性提供共同的參考。這裏所說的開放系統，實質上指的是遵循OSI參考模型和相關協議能夠實現互連的具有各種應用目的的計算機系統。
OSI採用了分層的結構化技術，共分七層，物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。
二、TCP/IP模型
OSI模型比較複雜且學術化，所以我們實際使用的TCP/IP模型，共分4層，鏈路層、網絡層、傳輸層、應用層。兩個模型之間的對應關係如圖所示：
無論什麼模型，每一個抽象層建立在低一層提供的服務上，並且爲高一層提供服務。
三、TCP/IP協議族
Transmission Control Protocol/Internet Protocol的簡寫，中譯名爲傳輸控制協議/因特網互聯協議，是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成。協議採用了4層的層級結構。然而在很多情況下，它是利用 IP 進行通信時所必須用到的協議羣的統稱。也就是說，它其實是個協議家族，由很多個協議組成，並且是在不同的層， 是互聯網的基礎通信架構。
四、TCP和UDP
在上述表格中，網際協議IP是TCP/IP中非常重要的協議。負責對數據加上IP地址（有發送它的主機的地址（源地址）和接收它的主機的地址（目的地址））和其他的數據以確定傳輸的目標。
而TCP和UDP都是傳輸層的協議，傳輸層主要爲兩臺主機上的應用程序提供端到端的通信。
但是TCP和UDP最不同的地方是，TCP提供了一種可靠的數據傳輸服務，TCP是面向連接的，也就是說，利用TCP通信的兩臺主機首先要經歷一個建立連接的過程，等到連接建立後纔開始傳輸數據，而且傳輸過程中採用“帶重傳的肯定確認”技術來實現傳輸的可靠性。TCP還採用一種稱爲“滑動窗口”的方式進行流量控制，發送完成後還會關閉連接。所以TCP要比UDP可靠的多。
UDP（User Datagram Protocol的簡稱， 中文名是用戶數據報協議）是把數據直接發出去，而不管對方是不是在接收，也不管對方是否能接收的了，也不需要接收方確認，屬於不可靠的傳輸，可能會出現丟包現象，實際應用中要求程序員編程驗證。
注意：
我們一些常見的網絡應用基本上都是基於TCP和UDP的，這兩個協議又會使用網絡層的IP協議。但是我們完全可以繞過傳輸層的TCP和UDP，直接使用IP，比如Linux中LVS，甚至直接訪問鏈路層，比如tcpdump程序就是直接和鏈路層進行通信的。
上圖中，其他一些協議的名稱解釋，瞭解即可：
ICMP 控制報文協議
IGMP internet組管理協議
ARP 地址解析協議
RARP 反向地址轉化協議
五、地址和端口號
我們常聽說 MAC 地址和 IP 地址。MAC地址就是在媒體接入層上使用的地址，也叫物理地址、硬件地址或鏈路地址，由網絡設備製造商生產時寫在硬件內部。MAC地址與網絡無關，也即無論將帶有這個地址的硬件（如網卡、集線器、路由器等）接入到網絡的何處，都有相同的MAC地址，它由廠商寫在網卡的BIOS裏，從理論上講，除非盜來硬件（網卡），否則是沒有辦法冒名頂替的。
IP 地址後者用來識別 TCP/IP 網絡中互連的主機和路由器。IP地址基於邏輯，比較靈活，不受硬件限制，也容易記憶。
在傳輸層也有這種類似於地址的概念，那就是端口號。端口號用來識別同一臺計算機中進行通信的不同應用程序。因此，它也被稱爲程序地址。
一臺計算機上同時可以運行多個程序。傳輸層協議正是利用這些端口號識別本機中正在進行通信的應用程序，並準確地將數據傳輸。
端口號的確定
• 標準既定的端口號：這種方法也叫靜態方法。它是指每個應用程序都有其指定的端口號。但並不是說可以隨意使用任何一個端口號。例如 HTTP、FTP、TELNET 等廣爲使用的應用協議中所使用的端口號就是固定的。這些端口號被稱爲知名端口號，分佈在 0~1023 之間；除知名端口號之外，還有一些端口號被正式註冊，它們分佈在 1024~49151 之間，不過這些端口號可用於任何通信用途。
• 時序分配法：服務器有必要確定監聽端口號，但是接受服務的客戶端沒必要確定端口號。在這種方法下，客戶端應用程序完全可以不用自己設置端口號，而全權交給操作系統進行分配。動態分配的端口號範圍在 49152~65535 之間。
端口號與協議
• 端口號由其使用的傳輸層協議決定。因此，不同的傳輸層協議可以使用相同的端口號。
• 此外，那些知名端口號與傳輸層協議並無關係。只要端口一致都將分配同一種應用程序進行處理。
六、TCP/IP介紹
TCP是面向連接的通信協議，通過三次握手建立連接，通訊完成時要拆除連接，由於TCP是面向連接的所以只能用於端到端的通訊。
TCP提供的是一種可靠的數據流服務，採用“帶重傳的肯定確認”技術來實現傳輸的可靠性。TCP還採用一種稱爲“滑動窗口”的方式進行流量控制，所謂窗口實際表示接收能力，用以限制發送方的發送速度。
如果IP數據包中有已經封好的TCP數據包，那麼IP將把它們向‘上’傳送到TCP層。TCP將包排序並進行錯誤檢查，同時實現虛電路間的連接。TCP數據包中包括序號和確認，所以未按照順序收到的包可以被排序，而損壞的包可以被重傳。
TCP將它的信息送到更高層的應用程序，例如Telnet的服務程序和客戶程序。應用程序輪流將信息送回TCP層，TCP層便將它們向下傳送到IP層，設備驅動程序和物理介質，最後到接收方。
面向連接的服務（例如Telnet、FTP、rlogin、X Windows和SMTP）需要高度的可靠性，所以它們使用了TCP。DNS在某些情況下使用TCP（發送和接收域名數據庫），但使用UDP傳送有關單個主機的信息。
6.1、TCP鏈接建立-三次握手
TCP 提供面向有連接的通信傳輸。面向有連接是指在數據通信開始之前先做好兩端之間的準備工作。
所謂三次握手是指建立一個 TCP 連接時需要客戶端和服務器端總共發送三個包以確認連接的建立。在socket編程中，這一過程由客戶端執行connect來觸發。
第一次握手：客戶端將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給服務器端，客戶端進入SYN_SENT狀態，等待服務器端確認。
第二次握手：服務器端收到數據包後由標誌位SYN=1知道客戶端請求建立連接，服務器端將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給客戶端以確認連接請求，服務器端進入SYN_RCVD狀態。
第三次握手：客戶端收到確認後，檢查ack是否爲J+1，ACK是否爲1，如果正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給服務器端，服務器端檢查ack是否爲K+1，ACK是否爲1，如果正確則連接建立成功，客戶端和服務器端進入ESTABLISHED狀態，完成三次握手，隨後客戶端與服務器端之間可以開始傳輸數據了。
通過linux下，tcpdump可以抓包，使用wireshark可以清楚地看到TCP建立連接的過程。
TCP的三次握手的漏洞
但是在TCP三次握手中是有一個缺陷的，就是如果我們利用三次握手的缺陷進行攻擊。這個攻擊就是SYN洪泛攻擊。三次握手中有一個第二次握手，服務端向客戶端應道請求，應答請求是需要客戶端IP的，服務端是需要知道客戶端IP的，攻擊者就僞造這個IP，往服務器端狂發送第一次握手的內容，當然第一次握手中的客戶端IP地址是僞造的，從而服務端忙於進行第二次握手但是第二次握手當然沒有結果，所以導致服務器端被拖累，死機。
當然我們的生活中也有可能有這種例子，一個家境一般的IT男去表白他的女神被拒絕了，理由是他家裏沒礦，IT男爲了報復，採用了洪泛攻擊，他請了很多人僞裝成有錢人去表白那位追求礦的女神，讓女生每次想交往時發現表白的人不見了同時還聯繫不上了。
面對這種攻擊，有以下的解決方案，最好的方案是防火牆。
無效連接監視釋放
這種方法不停監視所有的連接，包括三次握手的，還有握手一次的，反正是所有的，當達到一定(與)閾值時拆除這些連接，從而釋放系統資源。這種方法對於所有的連接一視同仁，不管是正常的還是攻擊的，所以這種方式不推薦。
延緩TCB分配方法
一般的做完第一次握手之後，服務器就需要爲該請求分配一個TCB（連接控制資源），通常這個資源需要200多個字節。延遲TCB的分配，當正常連接建立起來後再分配TCB則可以有效地減輕服務器資源的消耗。
使用防火牆
防火牆在確認了連接的有效性後，才向內部的服務器（Listener）發起SYN請求，
6.2、TCP鏈接的釋放-四次揮手（分手）
四次揮手即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個包以確認連接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發。
由於TCP連接是全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的連接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，但是在這個TCP連接上仍然能夠發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉。
- 客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
- 服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
- 客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最後的數據）。
- 服務器將最後的數據發送完畢後，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
- 客戶端收到服務器的連接釋放報文後，必鬚髮出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
抓包4次分手
6.3、TCP/IP中的數據包
每個分層中，都會對所發送的數據附加一個首部，在這個首部中包含了該層必要的信息，如發送的目標地址以及協議相關信息。通常，爲協議提供的信息爲包首部，所要發送的內容爲數據。在下一層的角度看，從上一層收到的包全部都被認爲是本層的數據。
網絡中傳輸的數據包由兩部分組成：一部分是協議所要用到的首部，另一部分是上一層傳過來的數據。首部的結構由協議的具體規範詳細定義。在數據包的首部，明確標明瞭協議應該如何讀取數據。反過來說，看到首部，也就能夠了解該協議必要的信息以及所要處理的數據。
① 應用程序處理
首先應用程序會進行編碼處理，這些編碼相當於 OSI 的表示層功能；
編碼轉化後，郵件不一定馬上被髮送出去，這種何時建立通信連接何時發送數據的管理功能，相當於 OSI 的會話層功能。
② TCP 模塊的處理
TCP 根據應用的指示，負責建立連接、發送數據以及斷開連接。TCP 提供將應用層發來的數據順利發送至對端的可靠傳輸。爲了實現這一功能，需要在應用層數據的前端附加一個 TCP 首部。
③ IP 模塊的處理
IP 將 TCP 傳過來的 TCP 首部和 TCP 數據合起來當做自己的數據，並在 TCP 首部的前端加上自己的 IP 首部。IP 包生成後，參考路由控制表決定接受此 IP 包的路由或主機。
④ 網絡接口（以太網驅動）的處理
從 IP 傳過來的 IP 包對於以太網來說就是數據。給這些數據附加上以太網首部並進行發送處理，生成的以太網數據包將通過物理層傳輸給接收端。
⑤ 網絡接口（以太網驅動）的處理
主機收到以太網包後，首先從以太網包首部找到 MAC 地址判斷是否爲發送給自己的包，若不是則丟棄數據。
如果是發送給自己的包，則從以太網包首部中的類型確定數據類型，再傳給相應的模塊，如 IP、ARP 等。這裏的例子則是 IP 。
⑥ IP 模塊的處理
IP 模塊接收到 數據後也做類似的處理。從包首部中判斷此 IP 地址是否與自己的 IP 地址匹配，如果匹配則根據首部的協議類型將數據發送給對應的模塊，如 TCP、UDP。這裏的例子則是 TCP。
另外嗎，對於有路由器的情況，接收端地址往往不是自己的地址，此時，需要藉助路由控制表，在調查應該送往的主機或路由器之後再進行轉發數據。
⑦ TCP 模塊的處理
在 TCP 模塊中，首先會計算一下校驗和，判斷數據是否被破壞。然後檢查是否在按照序號接收數據。最後檢查端口號，確定具體的應用程序。數據被完整地接收以後，會傳給由端口號識別的應用程序。
⑧ 應用程序的處理
接收端應用程序會直接接收發送端發送的數據。通過解析數據，展示相應的內容。
6.4、TCP的通訊原理
Socket套接字
Socket 的原意是“插座”，在計算機通信領域，socket 被翻譯爲“套接字”，它是計算機之間進行通信的一種約定或一種方式。通過 socket 這種約定，一臺計算機可以接收其他計算機的數據，也可以向其他計算機發送數據。TCP用主機的IP地址加上主機上的端口號作爲TCP連接的端點，這種端點就叫做套接字（socket）。
區分不同應用程序進程間的網絡通信和連接，主要有3個參數：通信的目的IP地址、使用的傳輸層協議(TCP或UDP)和使用的端口號。通過將這3個參數結合起來，與一個“插座”Socket綁定，應用層就可以和傳輸層通過套接字接口，區分來自不同應用程序進程或網絡連接的通信，實現數據傳輸的併發服務。
套接字對是一個定義該連接的兩個端點的四元組：本地IP地址、本地TCP端口號、外地IP地址、外地ＴＣＰ端口號。套接字對唯一標識一個網絡上的每個TCP連接。
TCP緩衝區
每個TCP的Socket的內核中都有一個發送緩衝區和一個接收緩衝區。現在我們假設用write()方法發送數據，使用 read()方法接收數據。
write()並不立即向網絡中傳輸數據，而是先將數據寫入緩衝區中，再由TCP協議將數據從緩衝區發送到目標機器。一旦將數據寫入到緩衝區，函數就可以成功返回，不管它們有沒有到達目標機器，也不管它們何時被髮送到網絡，這些都是TCP協議負責的事情。
TCP協議獨立於 write()函數，數據有可能剛被寫入緩衝區就發送到網絡，也可能在緩衝區中不斷積壓，多次寫入的數據被一次性發送到網絡，這取決於當時的網絡情況、當前線程是否空閒等諸多因素，不由程序員控制。
read()也是如此，也從輸入緩衝區中讀取數據，而不是直接從網絡中讀取。
總得來說，I/O緩衝區在每個TCP套接字中單獨存在；I/O緩衝區在創建套接字時自動生成；
6.5、TCP 的可靠性
在 TCP 中，當發送端的數據到達接收主機時，接收端主機會返回一個已收到消息的通知。這個消息叫做確認應答（ACK）。當發送端將數據發出之後會等待對端的確認應答。如果有確認應答，說明數據已經成功到達對端。反之，則數據丟失的可能性很大。
在一定時間內沒有等待到確認應答，發送端就可以認爲數據已經丟失，並進行重發。由此，即使產生了丟包，仍然能夠保證數據能夠到達對端，實現可靠傳輸。
未收到確認應答並不意味着數據一定丟失。也有可能是數據對方已經收到，只是返回的確認應答在途中丟失。這種情況也會導致發送端誤以爲數據沒有到達目的地而重發數據。
此外，也有可能因爲一些其他原因導致確認應答延遲到達，在源主機重發數據以後纔到達的情況也屢見不鮮。此時，源主機只要按照機制重發數據即可。
對於目標主機來說，反覆收到相同的數據是不可取的。爲了對上層應用提供可靠的傳輸，目標主機必須放棄重複的數據包。爲此我們引入了序列號。
序列號是按照順序給發送數據的每一個字節（8位字節）都標上號碼的編號。接收端查詢接收數據 TCP 首部中的序列號和數據的長度，將自己下一步應該接收的序列號作爲確認應答返送回去。通過序列號和確認應答號，TCP 能夠識別是否已經接收數據，又能夠判斷是否需要接收，從而實現可靠傳輸。
6.6、TCP中的滑動窗口
發送方和接收方都會維護一個數據幀的序列，這個序列被稱作窗口。發送方的窗口大小由接收方確認，目的是控制發送速度，以免接收方的緩存不夠大導致溢出，同時控制流量也可以避免網絡擁塞。
在TCP 的可靠性的圖中，我們可以看到，發送方每發送一個數據接收方就要給發送方一個ACK對這個數據進行確認。只有接收了這個確認數據以後發送方纔能傳輸下個數據。
存在的問題：如果窗口過小，當傳輸比較大的數據的時候需要不停的對數據進行確認，這個時候就會造成很大的延遲。
如果窗口過大，我們假設發送方一次發送100個數據，但接收方只能處理50個數據，這樣每次都只對這50個數據進行確認。發送方下一次還是發送100個數據，但接受方還是隻能處理50個數據。這樣就避免了不必要的數據來擁塞我們的鏈路。
因此，我們引入了滑動窗口。滑動窗口通俗來講就是一種流量控制技術。
它本質上是描述接收方的TCP數據報緩衝區大小的數據，發送方根據這個數據來計算自己最多能發送多長的數據，如果發送方收到接收方的窗口大小爲0的TCP數據報，那麼發送方將停止發送數據，等到接收方發送窗口大小不爲0的數據報的到來。
首先是第一次發送數據這個時候的窗口大小是根據鏈路帶寬的大小來決定的。我們假設這個時候窗口的大小是3。這個時候接受方收到數據以後會對數據進行確認告訴發送方我下次希望手到的是數據是多少。這裏我們看到接收方發送的ACK=3(這是發送方發送序列2的回答確認，下一次接收方期望接收到的是3序列信號)。這個時候發送方收到這個數據以後就知道我第一次發送的3個數據對方只收到了2個。就知道第3個數據對方沒有收到。下次在發送的時候就從第3個數據開始發。
此時窗口大小變成了2 。
於是發送方發送2個數據。看到接收方發送的ACK是5就表示他下一次希望收到的數據是5，發送方就知道我剛纔發送的2個數據對方收了這個時候開始發送第5個數據。
這就是滑動窗口的工作機制，當鏈路變好了或者變差了這個窗口還會發生變話，並不是第一次協商好了以後就永遠不變了。
所以滑動窗口協議，是TCP使用的一種流量控制方法。該協議允許發送方在停止並等待確認前可以連續發送多個分組。由於發送方不必每發一個分組就停下來等待確認，因此該協議可以加速數據的傳輸。
只有在接收窗口向前滑動時（與此同時也發送了確認），發送窗口才有可能向前滑動。
收發兩端的窗口按照以上規律不斷地向前滑動，因此這種協議又稱爲滑動窗口協議。
七、UDP協議
UDP是面向無連接的通訊協議，UDP數據包括目的端口號和源端口號信息，由於通訊不需要連接，所以可以實現廣播發送。
UDP通訊時不需要接收方確認，屬於不可靠的傳輸，可能會出現丟包現象，實際應用中要求程序員編程驗證。
UDP與TCP位於同一層，但它不管數據包的順序、錯誤或重發。因此，UDP不被應用於那些面向連接的服務，UDP主要用於那些面向查詢---應答的服務，例如NFS。相對於FTP或Telnet，這些服務需要交換的信息量較小。使用UDP的服務包括NTP（網絡時間協議）和DNS（DNS也使用TCP），包總量較少的通信（DNS、SNMP等）；2.視頻、音頻等多媒體通信（即時通信）；3.限定於 LAN 等特定網絡中的應用通信；4.廣播通信（廣播、多播）。
常用的QQ，就是一個以UDP爲主，TCP爲輔的通訊協議。
TCP 和 UDP 的優缺點無法簡單地、絕對地去做比較：TCP 用於在傳輸層有必要實現可靠傳輸的情況；而在一方面，UDP 主要用於那些對高速傳輸和實時性有較高要求的通信或廣播通信。TCP 和 UDP 應該根據應用的目的按需使用。
八、HTTP協議介紹
HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。
我們使用http來訪問Web上某個資源，比如html/文本、word、avi電影、其他資源。
Content-Type指示響應的內容，這裏是text/html表示HTML網頁。請注意，瀏覽器就是依靠Content-Type來判斷響應的內容是網頁還是圖片，是視頻還是音樂。瀏覽器並不靠URL來判斷響應的內容，所以，即使URL是http://example.com/abc.jpg，它也不一定就是圖片。
HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和建立連接。URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息。
URL，全稱是UniformResourceLocator, 中文叫統一資源定位符,是互聯網上用來標識某一處資源的地址。
8.1、URI和URL的區別
URI是個純粹的句法結構，用於指定標識Web資源的字符串的各個不同部分。URL是URI的一個特例，它包含了定位Web資源的足夠信息。其他URI，比如
mailto：[email protected]
則不屬於定位符，因爲根據該標識符無法定位任何資源。
URI 是統一資源標識符，而 URL 是統一資源定位符。因此，籠統地說，每個 URL 都是 URI，但不一定每個 URI 都是 URL。這是因爲 URI 還包括一個子類，即統一資源名稱 (URN)，它命名資源但不指定如何定位資源。上面的 mailto就是一個URN 的示例。
URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明瞭如何locate這個資源。
8.2、一個完整的URL
包括以下幾部分：
http://www.enjoyedu.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
1.協議部分：該URL的協議部分爲“http：”，這代表網頁使用的是HTTP協議。在Internet中可以使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後面的“//”爲分隔符
2.域名部分：該URL的域名部分爲“www.enjoyedu.com”。一個URL中，也可以使用IP地址作爲域名使用
3.端口部分：跟在域名後面的是端口，域名和端口之間使用“:”作爲分隔符。端口不是一個URL必須的部分，如果省略端口部分，將採用默認端口
4.虛擬目錄部分：從域名後的第一個“/”開始到最後一個“/”爲止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/news/”
5.文件名部分：從域名後的最後一個“/”開始到“？”爲止，是文件名部分，如果沒有“?”,則是從域名後的最後一個“/”開始到“#”爲止，是文件部分，如果沒有“？”和“#”，那麼從域名後的最後一個“/”開始到結束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個URL必須的部分，如果省略該部分，則使用默認的文件名
6.錨部分：從“#”開始到最後，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分
7.參數部分：從“？”開始到“#”爲止之間的部分爲參數部分，又稱搜索部分、查詢部分。本例中的參數部分爲“boardID=5&ID=24618&page=1”。參數可以允許有多個參數，參數與參數之間用“&”作爲分隔符。
8.3、HTTP請求的傳輸過程
首先作爲發送端的客戶端在應用層（HTTP 協議）發出一個想看某個 Web 頁面的 HTTP 請求。
接着，爲了傳輸方便，在傳輸層（TCP 協議）把從應用層處收到的數據（HTTP 請求報文）進行分割，並在各個報文上打上標記序號及端口號後轉發給網絡層。
在網絡層（IP 協議），增加作爲通信目的地的 MAC 地址後轉發給鏈路層。這樣一來，發往網絡的通信請求就準備齊全了。
接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端發送過來的 HTTP請求。
一次完整http請求的過程
首先進行DNS域名解析（本地瀏覽器緩存、操作系統緩存或者DNS服務器）
建立 TCP 連接
在HTTP工作開始之前，客戶端首先要通過網絡與服務器建立連接，該連接是通過 TCP 來完成的，該協議與 IP 協議共同構建 Internet，即著名的 TCP/IP 協議族，因此 Internet 又被稱作是 TCP/IP 網絡。HTTP 是比 TCP 更高層次的應用層協議，根據規則，只有低層協議建立之後，才能進行高層協議的連接，因此，首先要建立 TCP 連接，一般 TCP 連接的端口號是80；
• 客戶端向服務器發送請求命令
一旦建立了TCP連接，客戶端就會向服務器發送請求命令；
例如：GET/sample/hello.jsp HTTP/1.1
• 客戶端發送請求頭信息
客戶端發送其請求命令之後，還要以頭信息的形式向服務器發送一些別的信息，之後客戶端發送了一空白行來通知服務器，它已經結束了該頭信息的發送；
• 服務器應答
客戶端向服務器發出請求後，服務器會客戶端返回響應；
例如： HTTP/1.1 200 OK
響應的第一部分是協議的版本號和響應狀態碼
• 服務器返回響應頭信息
正如客戶端會隨同請求發送關於自身的信息一樣，服務器也會隨同響應向用戶發送關於它自己的數據及被請求的文檔；
• 服務器向客戶端發送數據
服務器向客戶端發送頭信息後，它會發送一個空白行來表示頭信息的發送到此爲結束，接着，它就以 Content-Type 響應頭信息所描述的格式發送用戶所請求的實際數據；
• 服務器關閉 TCP 連接
一般情況下，一旦服務器向客戶端返回了請求數據，它就要關閉 TCP 連接，然後如果客戶端或者服務器在其頭信息加入了這行代碼 Connection:keep-alive ，TCP 連接在發送後將仍然保持打開狀態，於是，客戶端可以繼續通過相同的連接發送請求。保持連接節省了爲每個請求建立新連接所需的時間，還節約了網絡帶寬。
以下爲整個HTTP請求的抓包
8.4、HTTP 協議報文結構
用於 HTTP 協議交互的信息被稱爲 HTTP 報文。請求端（客戶端）的 HTTP 報文叫做請求報文；響應端（服務器端）的叫做響應報文。HTTP 報文本身是由多行（用 CR+LF 作換行符）數據構成的字符串文本。
HTTP 報文大致可分爲報文首部和報文主體兩部分。兩者由最初出現的空行（CR+LF）來劃分。通常，並不一定有報文主體。
請求報文結構
請求報文的首部內容由以下數據組成：
請求行 —— 包含用於請求的方法、請求 URI 和 HTTP 版本。
首部字段 —— 包含表示請求的各種條件和屬性的各類首部。（通用首部、請求首部、實體首部以及RFC裏未定義的首部如 Cookie 等）
響應報文結構
狀態行 —— 包含表明響應結果的狀態碼、原因短語和 HTTP 版本。
首部字段 —— 包含表示請求的各種條件和屬性的各類首部。（通用首部、響應首部、實體首部以及RFC裏未定義的首部如 Cookie 等）
