整理常見的網絡面試題用於個人複習，文章後面附上參考鏈接，侵刪！

網絡模型

1 OSI七層網絡協議模型

ISO（國際標準化組織）制定了一個國際標準OSI（開放式通信系統互聯參考模型）

層	功能	說明
物理層	比特流的傳輸和傳輸介質的特性標準（網線，交換機）	物理層不是指物理設備或物理媒體，而是傳輸介質的特性標準，例如連接器與網線的規格是什麼？比特流與電子信號之間如何切換？標準：IEEE 802.1A, IEEE 802.2到IEEE 802.11
數據鏈路層	數據幀和比特流之間的轉換，（提供介質訪問，鏈路管理等）主要負責數據鏈路的建立，維持和拆除，確保在一段物理鏈路上的數據幀的正確傳輸，建立相鄰節點之間的數據傳輸	定義在單個鏈路傳輸的數據規則，數據鏈路層是相鄰兩直接鏈接節點間的通信協議，它不能解決數據經過通信網絡中多個轉接節點的通訊問題：以太網ARP、RARP、SDLC、HDLC、PPP、STP、幀中繼
網絡層	尋址(識別目標機器的IP地址)和路由選擇 ,要以報文分組以最佳的路徑通過網絡到達目的主機而提供服務，讓網絡用戶不必關注網絡拓撲的結構與之通訊所使用的協議	IP、IPX、RIP、OSPF
傳輸層	（建立主機端到端的鏈接）傳輸層主要利用通信子網，進行通信的來兩個主機提供可靠的，透明的，端到端多路數據傳輸服務	TCP,UDP
會話層	負責建立和斷開通信連接, 不同用戶和機器之間建立維護管理會話,當前數據在傳輸和封裝時是以什麼樣的會話方式進行通訊	SSL/TLS
表示層	固有的設備的數據格式和網絡標準的數據格式之間的轉換。	不同設備對同一比特流解釋的結果可能會不同，表示層進行數據格式的轉換。確保一個系統的應用層信息可被另一個系統應用層讀取
應用層	（提供應用程序之間的通訊）	各種應用層協議 HTTP, SMTP, TELNET,TFTP,SNMP, DNS

2 OSI七層和TCP/IP四層的關係

OSI引入了服務、接口、協議、分層的概念，TCP/IP借鑑了OSI的這些概念建立TCP/IP模型。
OSI先有模型，後有協議，先有標準，後進行實踐；而TCP/IP則相反，先有協議和應用再提出了模型，且是參照的OSI模型。
OSI是一種理論下的模型，而TCP/IP已被廣泛使用，成爲網絡互聯事實上的標準。

TCP：transmission control protocol 傳輸控制協議

UDP：user data protocol 用戶數據報協議

OSI七層網絡模型	TCP/IP四層概念模型	對應網絡協議
應用層（Application）	應用層	HTTP、TFTP, FTP, NFS, WAIS、SMTP
表示層（Presentation）	應用層
會話層（Session）	應用層
傳輸層（Transport）	傳輸層	TCP, UDP
網絡層（Network）	網絡層	IP, ICMP, ARP, RARP, AKP, UUCP
數據鏈路層（Data Link）	數據鏈路層	FDDI, Ethernet, Arpanet, PDN, SLIP, PPP
物理層（Physical）	數據鏈路層	IEEE 802.1A, IEEE 802.2到IEEE 802.11

2.1 TCP/IP四層概念模型-各層常見協議

應用層協議
1、超文本傳輸協議（HTTP）:萬維網的基本協議；
2、文件傳送協議FTP：提供交互式的訪問，基於客戶服務器模式，面向連接使用TCP可靠的運輸服務

主要功能:減少/消除不同操作系統下文件的不兼容性
3、文件傳輸（TFTP）簡單文件傳輸協議，使用UDP數據報，支持文件傳輸，不支持交互，TFTP代碼佔內存小 /
4、遠程登錄（Telnet），提供遠程訪問其它主機功能, 它允許用戶登錄internet主機，並在這臺主機上執行命令；
5、網絡管理（SNMP簡單網絡管理協議），該協議提供了監控網絡設備的方法，以及配置管理,統計信息收集,性能管理及安全管理等；
6、域名系統（DNS），域名解析協議，該系統用於在internet中將域名及其公共廣播的網絡節點轉換成IP地址。
7、DHCP動態主機配置協議: 發現協議中的引導文件名、空終止符、屬名或者空,DHCP供應協議中的受限目錄路徑名 Options –可選參數字段，參考定義選擇列表中的選擇文件
網路層協議
1、Internet協議（IP）；
2、Internet控制信息協議（ICMP）；
數據鏈路層協議
1、地址解析協議（ARP）；
2、反向地址解析協議（RARP）

TCP/IP

TCP/IP協議（一）網絡基礎知識

1. TCP協議和UDP協議

參考陳寶佳

TCP（Transmission Control Protocol，傳輸控制協議）是面向連接的協議，也就是說，在收發數據前，必須和對方建立可靠的連接。

1 TCP

1.1TCP的包頭結構

參考新綠

　　●源、目標端口號字段：佔16比特。TCP協議通過使用"端口"來標識源端和目標端的應用進程。端口號可以使用0到65535之間的任何數字。在收到服務請求時，操作系統動態地爲客戶端的應用程序分配端口號。在服務器端，每種服務在"衆所周知的端口"（Well-Know Port）爲用戶提供服務。。
　　●順序號字段：佔32比特。用來標識從TCP源端向TCP目標端發送的數據字節流，它表示在這個報文段中的第一個數據字節。
　　●確認號字段：只有ACK標誌爲1時，確認號字段纔有效。它包含目標端所期望收到源端的下一個數據字節。佔4個字節，期待收到對方下一個報文段的第一個數據字節的序號；序列號表示報文段攜帶數據的第一個字節的編號；而確認號指的是期望接收到下一個字節的編號；只有ACK標誌爲1時，確認號字段纔有效,當前報文段最後一個字節的編號+1即爲確認號。
　　●頭部長度字段：佔4比特。給出頭部佔32比特的數目。沒有任何選項字段的TCP頭部長度爲20字節；最多可以有60字節的TCP頭部。
　　●標誌位字段（U、A、P、R、S、F）：佔6比特。各比特的含義如下：
　　◆URG：緊急指針（urgent pointer）有效。爲1，表示某一位需要被優先處理
　　◆ACK：確認序號有效。
　　◆PSH：提示接收端應用程序立即從TCP緩衝區把數據讀走。接收方應該儘快將這個報文段交給應用層。
　　◆RST：重建連接。
　　◆SYN：發起一個連接。並在其序列號的字段進行序列號的初始值設定。建立連接，設置爲1。
　　◆FIN：用來釋放一個連接。FIN=1表示：此報文段的發送方的數據已經發送完畢，並要求釋放運輸連接
　　●窗口大小字段：佔16比特。此字段用來進行流量控制。單位爲字節數，這個值是本機期望一次接收的字節數。
　　●TCP校驗和字段：佔16比特。對整個TCP報文段，即TCP頭部和TCP數據進行校驗和計算，並由目標端進行驗證。
　　●緊急指針字段：佔16比特。它是一個偏移量，和序號字段中的值相加表示緊急數據最後一個字節的序號。
　　●選項字段：佔32比特。可能包括"窗口擴大因子"、"時間戳"等選項。

1.2 TCP三次握手四次揮手
tcp握手與揮手的過程參考eddyjoe

1.3 三次握手過程理解

第一次握手：建立連接時，客戶端發送SYN包（syn=x）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。
第二次握手：服務器收到SYN包，必須確認客戶的SYN（ack=x+1），同時自己也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=y+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手。

1.4 四次揮手過程理解
1）客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
2）服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3）客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最後的數據）。
4）服務器將最後的數據發送完畢後，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
5）客戶端收到服務器的連接釋放報文後，必鬚髮出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB線程控制塊後，才進入CLOSED狀態。
6）服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。

1.5 tcp 常見面試題

【問題1】爲什麼連接的時候是三次握手，關閉的時候卻是四次握手？

答：因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，“你發的FIN報文我收到了”。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。

【問題2】爲什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可能最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。在Client發送出最後的ACK回覆，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重複發送FIN片段。所以Client不能立即關閉，它必須確認Server接收到了該ACK。Client會在發送出ACK之後進入到TIME_WAIT狀態。Client會設置一個計時器，等待2MSL的時間。如果在該時間內再次收到FIN，那麼Client會重發ACK並再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網絡中最大的存活時間，2MSL就是一個發送和一個回覆所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP連接。

【問題3】爲什麼不能用兩次握手進行連接？

答：3次握手完成兩個重要的功能，既要雙方做好發送數據的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被髮送和確認。

現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作爲例子，考慮計算機S和C之間的通信，假定C給S發送一個連接請求分組，S收到了這個分組，併發送了確認應答分組。按照兩次握手的協定，S認爲連接已經成功地建立了，可以開始發送數據分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已準備好，不知道S建立什麼樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認爲連接還未建立成功，將忽略S發來的任何數據分組，只等待連接確認應答分組。而S在發出的分組超時後，重複發送同樣的分組。這樣就形成了死鎖。

【問題4】如果已經建立了連接，但是客戶端突然出現故障了怎麼辦？

TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設置爲2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉連接。

2 UDP

UDP（User Data Protocol，用戶數據報協議）是一個非連接的協議，傳輸數據之前源端和終端不建立連接，當它想傳送時就簡單地去抓取來自應用程序的數據，並儘可能快地把它扔到網絡上。在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬的限制；在接收端，UDP把每個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。

3.1 UDP的包頭結構

源端口 16位
目的端口 16位
長度 16位
校驗和 16位

3.2 UDP特點

1、是一個非連接的協議，傳輸數據之前源端和終端不建立連接，當它想傳送時就簡單地去抓取來自應用程序的數據，並儘可能快地把它扔到網絡上。
2、由於傳輸數據不建立連接，因此也就不需要維護連接狀態，包括收發狀態等，因此一臺服務機可同時向多個客戶機傳輸相同的消息。

3、UDP信息包的標題很短，只有8個字節，相對於TCP的20個字節信息包的額外開銷很小。

4、吞吐量不受擁擠控制算法的調節，只受應用軟件生成數據的速率、傳輸帶寬、源端和終端主機性能的限制。

5、UDP使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持複雜的鏈接狀態表（這裏面有許多參數）。

6、UDP是面向報文的。發送方的UDP對應用程序交下來的報文，在添加首部後就向下交付給IP層。既不拆分，也不合並，而是保留這些報文的邊界，因此，應用程序需要選擇合適的報文大小。

3 TCP與UDP區別總結

1、基於連接與無連接；

2、對系統資源的要求（TCP較多，UDP少）；

3、UDP程序結構較簡單；

4、流模式與數據報模式；

5、TCP保證數據正確性，UDP可能丟包；

6、TCP保證數據順序，UDP不保證。

TCP流模式和UDP數據報模式的區別
轉載jasononline侵刪
“TCP是一種流模式的協議，UDP是一種數據報模式的協議”，這句話相信大家對這句話已經耳熟能詳~但是，“流模式”與“數據包模式”在編程的時候有什麼區別呢？以下是我的理解，僅供參考！
1、TCP
打個比方比喻TCP，你家裏有個蓄水池，你可以裏面倒水，蓄水池上有個龍頭，你可以通過龍頭將水池裏的水放出來，然後用各種各樣的容器裝（杯子、礦泉水瓶、鍋碗瓢盆）接水。上面的例子中，往水池裏倒幾次水和接幾次水是沒有必然聯繫的，也就是說你可以只倒一次水，然後分10次接完。另外，水池裏的水接多少就會少多少；往裏面倒多少水，就會增加多少水，但是不能超過水池的容量，多出的水會溢出。
結合TCP的概念，水池就好比接收緩存，倒水就相當於發送數據，接水就相當於讀取數據。好比你通過TCP連接給另一端發送數據，你只調用了一次write，發送了100個字節，但是對方可以分10次收完，每次10個字節；你也可以調用10次write，每次10個字節，但是對方可以一次就收完。（假設數據都能到達）但是，你發送的數據量不能大於對方的接收緩存（流量控制），如果你硬是要發送過量數據，則對方的緩存滿了就會把多出的數據丟棄。這種情況是設置非阻塞I/O模型，會把內存耗盡，因爲socket是存在內核中的。
2、UDP
UDP和TCP不同，發送端調用了幾次write，接收端必須用相同次數的read讀完。UPD是基於報文的，在接收的時候，每次最多隻能讀取一個報文，報文和報文是不會合並的，如果緩衝區小於報文長度，則多出的部分會被丟棄。也就說，如果不指定MSG_PEEK標誌，每次讀取操作將消耗一個報文。
3、爲什麼
其實，這種不同是由TCP和UDP的特性決定的。TCP是面向連接的，也就是說，在連接持續的過程中，socket中收到的數據都是由同一臺主機發出的（劫持什麼的不考慮），因此，知道保證數據是有序的到達就行了，至於每次讀取多少數據自己看着辦。
而UDP是無連接的協議，也就是說，只要知道接收端的IP和端口，且網絡是可達的，任何主機都可以向接收端發送數據。這時候，如果一次能讀取超過一個報文的數據，則會亂套。比如，主機A向發送了報文P1，主機B發送了報文P2，如果能夠讀取超過一個報文的數據，那麼就會將P1和P2的數據合併在了一起，這樣的數據是沒有意義的。

2 IP

1 IP頭部結構

參考shouhuo123，IP頭部詳解
leeon_l,IP、TCP、UDP首部詳解.

24字節 6行

版本 | 頭部長度 | 服務類型 | 總長
標識符 | 標記 | 偏移
生存時間 | 協議 | 頭部校驗
源地址
目標地址
選項

各部結構組成詳解

1、第一個4字節（也就是第一行）：
（1）版本號（Version），4位；用於標識IP協議版本，IPv4是0100，IPv6是0110，也就是二進制的4和6。
（2）首部長度（Internet Header Length），4位；用於標識首部的長度，單位爲4字節，所以首部長度最大值爲：(2^4 - 1) * 4 = 60字節，但一般只推薦使用20字節的固定長度。
（3）服務類型（Type Of Service），8位；用於標識IP包的優先級，但現在並未使用。
（4）總長度（Total Length），16位；標識IP數據報的總長度，最大爲：2^16 -1 = 65535字節。

2、第二個四字節：
（1）標識（Identification），16位；用於標識IP數據報，如果因爲數據鏈路層幀數據段長度限制（也就是MTU，支持的最大傳輸單元），IP數據報需要進行分片發送，則每個分片的IP數據報標識都是一致的。
（2）標識（Flag），3位，但目前只有2位有意義；最低位爲MF，MF=1代表後面還有分片的數據報，MF=0代表當前數據報已是最後的數據報。次低位爲DF，DF=1代表不能分片，DF=0代表可以分片。
（3）片偏移（Fragment Offset），13位；代表某個分片在原始數據中的相對位置。

3、第三個四字節：
（1）生存時間（TTL），8位；以前代表IP數據報最大的生存時間，現在標識IP數據報可以經過的路由器數。
（2）協議（Protocol），8位；代表上層傳輸層協議的類型，1代表ICMP，2代表IGMP，6代表TCP，17代表UDP。
（3）校驗和（Header Checksum），16位；用於驗證數據完整性，計算方法爲，首先將校驗和位置零，然後將每16位二進制反碼求和即爲校驗和，最後寫入校驗和位置。
4、第四個四字節：源IP地址
5、第五個四字節：目的IP地址

HTTP

1. 請求過程

域名解析：先查應用緩存，系統緩存，讀取host。都沒有則UDP向DNS53端口發起請求。
建立TCP連接
（可能）TLS握手
發起HTTP請求
得到響應
數據渲染

引用艾倫lee, 個人複習使用，侵刪

1.瀏覽器根據域名解析IP地址
瀏覽器根據訪問的域名找到其IP地址。DNS查找過程如下：

瀏覽器緩存：首先搜索瀏覽器自身的DNS緩存（緩存的時間比較短，大概只有1分鐘，且只能容納1000條緩存），看自身的緩存中是否是有域名對應的條目，而且沒有過期，如果有且沒有過期則解析到此結束。
系統緩存：如果瀏覽器自身的緩存裏面沒有找到對應的條目，那麼瀏覽器會搜索操作系統自身的DNS緩存，如果找到且沒有過期則停止搜索解析到此結束。
路由器緩存：如果系統緩存也沒有找到，則會向路由器發送查詢請求。
ISP（互聯網服務提供商） DNS緩存：如果在路由緩存也沒找到，最後要查的就是ISP緩存DNS的服務器。

2. 瀏覽器與WEB服務器建立一個TCP連接

TCP的3次握手

3 瀏覽器給WEB服務器發送一個HTTP請求

3.1請求方法

一個HTTP請求報文由請求行（request line）、請求頭部（headers）、空行（blank line）和請求數據（request body）4個部分組成。

HTTP/1.1 定義的請求方法有8種：

GET
當客戶端要從服務器中讀取文檔時，當點擊網頁上的鏈接或者通過在瀏覽器的地址欄輸入網址來瀏覽網頁的，使用的都是GET方式。GET方法要求服務器將URL定位的資源放在響應報文的數據部分，會送給客戶端。使用GET方法時，請求參數和對應的值附加在URL後面，利用一個問號‘？’代表URL的結尾與請求參數的開始，傳遞參數長度受限制。例如，/index.jsp?id=100&op=bind。通過GET方式傳遞的數據直接放在地址中，所以GET方式的請求一般不包含“請求內容”部分，請求數據以地址的形式表現在請求行。地址中‘？’之後的部分就是通過GET發送的請求數據，各個數據之間用‘&’符號隔開。顯然這種方式不適合傳送私密數據。另外，由於不同的瀏覽器對地址的字符限制也有所不同，一半最多隻能識別1024個字符，所以如果需要傳送大量數據的時候，也不適合使用GET方式。如果數據是英文字母/數字，原樣發送；如果是空格，轉換爲+；如果是中文/其他字符，則直接把字符串用BASE64加密，得出：%E4%BD%A0%E5%A5%BD，其中%XX中的XX爲該符號以16進製表示的ASCII
POST
允許客戶端給服務器提供信息較多。POST方法將請求參數封裝在HTTP請求數據中，以名稱/值的形式出現，可以傳輸大量數據，這樣POST方式對傳送的數據大小沒有限制，而且也不會顯示在URL中。POST方式請求行中不包含數據字符串，這些數據保存在“請求內容”部分，各數據之間也是使用‘&’符號隔開。POST方式大多用於頁面的表單中。因爲POST也能完成GET的功能，因此多數人在設計表單的時候一律都使用POST方式，其實這是一個誤區。GET方式也有自己的特點和優勢，我們應該根據不同的情況來選擇是使用GET還是使用POST。

4 服務器端響應HTTP請求，瀏覽器得到HTML代碼

HTTP響應報文由狀態行（status line）、相應頭部（headers）、空行（blank line）和響應數據（response body）4個部分組成

5 瀏覽器解析HTML代碼，並請求HTML代碼中的資源

瀏覽器拿到HTML文件後，開始解析HTML代碼，遇到靜態資源時，就向服務器端去請求下載。

用於存放需要返回給客戶端的數據信息。

HTTP/1.1 200 OK　　狀態行

Date: Sun, 17 Mar 2013 08:12:54 GMT　　響應頭部

Server: Apache/2.2.8 (Win32) PHP/5.2.5

X-Powered-By: PHP/5.2.5

Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Content-Length: 4393

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive

Content-Type: text/html; charset=utf-8

　　空行


<html>　　響應數據

<head>

<title>HTTP響應示例<title>

</head>

<body>

Hello HTTP!

</body>

</html>

6 關閉TCP連接，瀏覽器對頁面進行渲染呈現給用戶

瀏覽器利用自己內部的工作機制，把請求到的靜態資源和HTML代碼進行渲染，呈現給用戶。

2 HTTP的請求和響應的格式

參考fengdashu

2.1.請求構成
• 請求（方法 | URI | 協議版本）
• 請求頭
• 請求正文

下面是一個請求的例子：
GET/sample.jspHTTP/1.1 ：請求方法/url/協議和協議的版本
Accept:image/gif.image/jpeg,/ ：客戶端可以接受的數據格式
Accept-Language:zh-cn ：
Connection:Keep-Alive ：連接狀態，使用TCP持久連接，請求複用
Host:localhost：請求的服務器域名
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0) 瀏覽器端瀏覽器型號和版本
Accept-Encoding:gzip,deflate ：可接受的壓縮類型 gzip,deflate
username=jinqiao&password=1234 ：請求的內容（請求頭和請求正文之間是一個空行，它表示請求頭已經結束）

2.2 響應構成
HTTP響應與HTTP請求相似，HTTP響應也由3個部分構成：
1）狀態行（協議 | 狀態碼 | 原因）例如: HTTP/1.1 200 OK
2）響應頭
3）響應正文

在接收和解釋請求消息後，服務器會返回一個HTTP響應消息。
狀態行由協議版本、數字形式的狀態代碼、及相應的狀態描述，各元素之間以空格分隔。
格式: HTTP-Version Status-Code Reason-Phrase CRLF
例如: HTTP/1.1 200 OK

狀態代碼
狀態代碼由3位數字組成，表示請求是否被理解或被滿足。
狀態描述：
狀態描述給出了關於狀態代碼的簡短的文字描述。
狀態代碼的第一個數字定義了響應的類別，後面兩位沒有具體的分類。
第一個數字有五種可能的取值：

1xx: 指示信息—表示請求已接收，繼續處理。
2xx: 成功—表示請求已經被成功接收、理解、接受。
3xx: 重定向—要完成請求必須進行更進一步的操作。
4xx: 客戶端錯誤—請求有語法錯誤或請求無法實現。
5xx: 服務器端錯誤—服務器未能實現合法的請求。

常見狀態碼
200 OK 客戶端請求成功
204 NO CONTENT
206 Partial Content

301 永久重定向
302 臨時重定向
303 臨時GET重定向
304 緩存重定向

400 Bad Request 客戶端請求有語法錯誤，不能被服務器所理解。
401 Unauthonzed 請求未經授權。這個狀態代碼必須和WWW-Authenticate報頭域一起使用
403 Forbidden 服務器收到請求，但是拒絕提供服務。服務器通常會在響應正文中給出不提供服務的原因
404 Not Found 請求的資源不存在，例如，輸入了錯誤的URL

500 Internal Server Error 服務器發生不可預期的錯誤，導致無法完成客戶端的請求。
503 Service Unavailable 服務器當前不能夠處理客戶端的請求，在一段時間之後，服務器可能會恢復正常

查看http請求和響應頭的方法

使用chrome瀏覽器自帶的開發者工具查看http頭的方法
1.在網頁任意地方右擊選擇審查元素或者按下 shift+ctrl+c或者F12, 打開chrome自帶的調試工具;
2.選擇network標籤, 刷新網頁(在打開調試工具的情況下刷新);
3.刷新後在左邊找到該網頁url,點擊後右邊選擇headers,就可以看到當前網頁的http請求和響應

3 HTTP各個版本

轉載 再見阿郎 侵刪
3.1 http 1.0：
引入了新的命令POST和HEAD（http數據頭部）命令

每個TCP連接只能發送一個請求，發送數據完畢，連接就關閉，如果還要請求其他資源，就必須再新建一個連接
頭信息是 ASCII 碼，後面數據可爲任何格式。服務器迴應時會告訴客戶端，數據是什麼格式，即Content-Type字段的作用。這些數據類型總稱爲MIME即多用途互聯網郵件擴展，每個值包括一級類型和二級類型，預定義的類型，也可自定義類型, 常見Content-Type值：text/xml image/jpeg audio/mp3

3.2 http 1.1
新增方法：PUT、PATCH、OPTIONS、DELETE

引入了持久連接（persistent connection），即TCP連接默認不關閉，可以被多個請求複用，不用聲明Connection: keep-alive。對於同一個域名，大多數瀏覽器允許同時建立6個持久連接引入了管道機制，即在同一個TCP連接裏，客戶端可以同時發送多個請求，進一步改進了HTTP協議的效率

同一個TCP連接裏，所有的數據通信是按次序進行的。服務器只能順序處理迴應，前面的迴應慢，會有許多請求排隊，造成"隊頭堵塞"（Head-of-line blocking）

爲避免上述問題，兩種方法：一是減少請求數，二是同時多開持久連接

其實http1.1還是有些問題沒有解決的
1.傳輸數據是明文
2.header頭部數據太長
3.每次傳輸還是要重新連接
4.server不能主動push

這樣就推動了http2.0的出現

3.3HTTP2.0
HTTP2.0是SPDY（谷歌公司研發的https的一種協議）的升級版
1.頭信息和數據體都是二進制，稱爲頭信息幀和數據幀
2.複用TCP連接，在一個連接裏，客戶端和瀏覽器都可以同時發送多個請求或迴應，且不用按順序一一對應，避免了“隊頭堵塞“,此雙向的實時通信稱爲多工（Multiplexing）
3.引入頭信息壓縮機制（header compression）,頭信息使用gzip或compress壓縮後再發送；客戶端和服務器同時維護一張頭信息表，所有字段都會存入這個表，生成一個索引號，不發送同樣字段，只發送索引號，提高速度
4.HTTP/2 允許服務器未經請求，主動向客戶端發送資源，即服務器推送（server push）

面試題：http1.0和http1.1的區別

長連接
HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，彌補了HTTP1.0每次請求都要創建連接的缺點

Q: HTTP的特點是無狀態的，多個請求之間是沒有關係的，這是不是矛盾了？

HTTP的無狀態是指不同請求間協議內容無相關性，即本次請求與上次請求沒有內容的依賴關係，本次響應也只針對本次請求的數據，至於服務器應用程序爲用戶保存的狀態是屬於應用層，與協議是無關的。

keep-alive表示tcp的連接可以複用，指的是利用已有的傳輸通道進行http協議內容的傳輸，省去創建/關閉連接的開銷達到提升性能的效果。應用程序其實一般不關心這次HTTP請求的TCP傳輸細節，只關心HTTP協議的內容，因此只有複用TCP連接時做好必要的數據重置，是不算有狀態的。
緩存處理
在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來做爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略
帶寬優化和網絡連接的使用
HTTP1.0中，存在一些浪費帶寬的現象，例如：客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，並且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），方便了開發者自由的選擇以便於充分利用帶寬和連接
錯誤通知的管理
在HTTP1.1中新增24個狀態響應碼，如
409（Conflict）表示請求的資源與資源當前狀態衝突；.
410（Gone）表示服務器上的某個資源被永久性的刪除
Host頭處理
在HTTP1.0中認爲每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）

HTTPS

轉載 Big shark@LX

HTTPS是什麼

HTTPS中的 S 就是指 SSL/TLS（SSL“安全套接層”協議，TLS“安全傳輸層”協議，都屬於是加密協議,在其網絡數據傳輸中起到保護隱私和數據的完整性），HTTPS 是在 HTTP 的基礎上，利用 SSL/TLS 加密數據包。

HTTPS主要目的

對數據加密
驗證網站服務器身份

HTTPS怎麼對數據進行加密

兩種數據加密方式：

對稱加密：所謂對稱就是指兩邊一樣發送方和接收方都用的同一個密鑰，加密解密都是同一個密鑰從始至終只需要保存一個密鑰就行。
非對稱加密：發送方和接收方使用一對密鑰，即公鑰和私鑰。一般私鑰是保密不能被泄露的，公鑰可以對外傳播。我們可以用公鑰加密私鑰解密（數據加密）也可用私鑰加密公鑰解密。

https結合兩種了加密方式，採用混合加密。在傳遞過程把我們的對稱加密中的密鑰用非對稱加密的方式去傳遞。

客戶端生成會話祕鑰就是我們對稱加密生成的密鑰。
它用公鑰加密之後進行傳遞(這個時候被加密的不是數據是這個會話祕鑰等於把鑰匙加密了) 這裏的公鑰就是非對稱加密中的公鑰他是由服務器傳遞過去的（對外公開）。
服務端用非對稱加密的私鑰去解密拿到我們的會話祕鑰。
客戶端和服務端都能用同一個會話祕鑰進行加解密了。

就算傳輸過程被攻擊者截取到了被加密的會話祕鑰他沒有服務器的私鑰是無法得到會話祕鑰的。

HTTPS 怎麼驗證網站服務器身份

HTTPS 第二個目的是對網站服務器進行真實身份認證。目前我們已經解決了數據加密的問題，雖然攻擊者無法解密數據，但是他可以篡改數據，我們怎麼知道數據沒被動過呢？

數據被篡改怎麼辦

這個時候就要使用數字簽名了，數字簽名：將原文（部分數據關鍵信息）先用 Hash 函數生成消息摘要，然後用發送者的私鑰加密生成數字簽名 與原文一起傳送給接收者。

兩個關鍵點：

Hash 算法計算生成信息摘要
私鑰加密生成數字簽名

客戶端如何校驗數字簽名呢？（利用服務器私鑰加密，公鑰解密）客戶端收到服務器發過來的數字簽名之後：

用服務端的公鑰去解密數字簽名得到消息摘要（原始未被篡改的）
用 Hash 函數對收到的原文計算生成一個摘要信息（可能會被篡改的）

如果兩個信息摘要一致，說明數據沒有被篡改。

但是！！最後還有一個很關鍵的點是：我們剛剛所有的假設都基於客戶端的公鑰是服務器傳遞過來的，那如果攻擊者僞造了服務器的公鑰怎麼辦呢？

2.服務器公鑰被篡改怎麼辦

這時候就要使用數字證書了，數字證書認證機構（CA）處於客戶端與服務器雙方都可信賴的第三方機構的立場上。

服務端向 CA 申請數字證書，審覈通過後 CA 會向申請者簽發認證文件-證書，包含以下內容：

整數的頒佈機構CA
證書有效日期
公鑰
簽名
證書所有者

拿到數字證書後，服務器傳遞數字證書給客戶端.

客戶端怎麼校驗數字證書
步驟如下：

首先瀏覽器讀取證書中的證書所有者、有效期等信息進行一一校驗。
瀏覽器開始查找操作系統中已內置的受信任的證書發佈機構 CA，與服務器發來的證書中的頒發者 CA 比對，用於校驗證書是否爲合法機構頒發。
如果找不到，瀏覽器就會報錯，說明服務器發來的證書是不可信任的。如果找到，那麼瀏覽器就會從操作系統中取出頒發者 CA 的公鑰，然後對服務器發來的證書裏面的簽名進行解密。
瀏覽器使用相同的 Hash 算法根據證書內容計算出信息摘要，將這個計算的值與證書解密的值做對比。
對比結果一致，則證明服務器發來的證書合法，沒有被冒充。此時瀏覽器就可以讀取證書中的公鑰，用於後續加密了。

參考文獻

[1] 菜鳥的進擊，網絡模型.
[2] 小皮皮鴨
[3] 左手指月的博客
[4] 再見阿郎
[5] 新綠, TCP、UDP、IP包頭結構分析（轉）.
[6] fengdashu, http協議—請求和響應報文的構成.
[7] eddyjoeTCP的三次握手和四次揮手，以及爲什麼要三次握手，而不是二次？

[8] Big shark@LX,程序員追分 ,看了這篇HTTPS，不要再說不會了！

計算機網絡-面試題吐血整理

計算機網絡-面試題整理

網絡模型

1 OSI七層網絡協議模型

2 OSI七層和TCP/IP四層的關係

TCP/IP