本文經過借鑑書籍資料、他人博客總結出的知識點，歡迎提問
一. 一些概念：
- 封裝：在應用程序數據發送到物理網絡之前，將沿着協議棧從上往下傳遞，每一層協議都在上層數據的基礎上加上自己的頭部信息（尾部信息），來實現該層功能。
![封裝]()
經過數據鏈路層封裝的數據，傳輸媒介不同，幀的類型也不同，上述圖用的是最常見的以太網幀。
二. TCP/IP 協議簇的部分常見協議及其默認端口
- 超文本傳輸協議：HTTP：萬維網的基本協議 端口：80
- 文件傳輸：ftp 端口：20，21
- 簡單文件傳輸協議：TFTP(Trivial File Transfer Protocol)：搭建無人值守安裝服務器 端口：69
- 遠程登陸：Telnet 端口：23
- 網絡管理：SNMP：簡單網絡管理協議 端口：161
- 傳輸控制協議：TCP（transmission control protocol）
- 用戶數據報協議：UTP（user data protocol）
- Internet 協議（IP）
- Internet 控制信息協議：ICMP
- 地址解析協議：ARP
- 反向地址解析協議：RARP
- 域名解析服務：DNS
三. 一些常見的面試問題：
1 TCP/IP 四層體系結構：
答： TCP/IP 協議族是一個四層的協議系統， 從上到下依次是：應用層，傳輸層，網絡層，網絡訪問層。
應用層：它支持網絡應用，提供與本地操作環境相交互的接口。
傳輸層：提供錯誤控制和確認功能，並充當網絡應用程序的接口。
網際層：提供邏輯尋址和路由選擇。
網絡訪問層：提供與物理網絡連接的接口。
2 OSI 七層模型：
- 從上到下依次是：應用層，表示層，會話層，傳輸層，網絡層，數據鏈路層，物理層。
3. 傳輸層協議：TCP 與 UDP 區別
答：
- TCP 是傳輸控制協議，提供的是面向連接的，可靠的字節流服務。實際數據傳輸之前服務器和客戶端要進行三次握手，會話結束後四次揮手結束連接。
- UDP 是用戶數據報協議，是無連接的。因爲無連接，而且沒有超時重發機制，所以 UDP 傳輸速度很快。主要用於視頻傳輸 （但其實現在各大視頻商都是用 HTTP 協議，而 HTTP 是基於 TCP），實時視頻。
- TCP 保證數據按序到達，提供流量控制和擁塞控制，在網絡擁堵的時候會減慢發送字節數，而 UDP 不管網絡是否擁堵。
- TCP 是連接的，所以服務是一對一服務，而 UDP 可以 1 對 1，也可以 1 對多（多播），也可以多對多。
4. TCP窗口機制
- 滑動窗口協議是傳輸層進行流量控制的一種措施，接收方通過通知發送方自己的窗口大小，從而控制發送方的發送速度，從而達到防止發送方發送速度過快而導致自己被淹沒的目的，並且滑動窗口分爲接收窗口和發送窗口。TCP 的滑動窗口的可靠性是建立在“確認重傳”基礎上的。發送窗口只有收到對方對於本段發送窗口內字節的 ACK 確認，纔會移動發送窗口的左邊界。接受窗口只有在前面所有的段都確認的情況下才會移動左邊界。當在前面還有字節未接受但收到後面字節的情況下，窗口不會移動，並不對後續字節確認。以此確保對方會對這些數據重傳。
- TCP 中窗口大小是指 tcp 協議一次傳輸多少數據。
- TCP 窗口機制有兩種，一種是固定窗口大小，另一種是滑動窗口。
- 因爲 TCP 是順序發送的，操作系統將這些數據包一批一批的發送給對方，就像一個窗口，不停地往後移動，所以，我們稱之爲 TCP 滑動窗口協議。
- 在 TCP中，窗口的大小是在 TCP 三次握手後協定的，並且窗口的大小並不是固定的，而是會隨着網絡的情況以及自身處理能力的變化進行調整。
- 對於發送端來說，即將要發送的數據包排成一個隊列，對於發送者來說，數據包總共分成四類。分別是在窗口前的，已經發送給接收方，並且收到了接收方的答覆，我們稱之爲已發送。在窗口中的，有兩種狀態，一個是已經發送給接收方，但是接收方還沒確認送達，我們稱之爲已發送未確認，另外一個是可以發送了，但是還沒有發送，我們稱之爲允許發送未發送。最後的是在窗口外面的，我們稱之爲不可發送，除非窗口滑到此處，否則不會進行發送。一旦前面的數據已經得到服務端確認了，這個窗口就會慢慢地往後滑。
5. 什麼是面向連接 & 面向無連接：
答：
- 面向連接：是指通信雙方在通信時，要事先建立一條通信線路。其有三個過程：建立連接、使用連接和釋放連接。
- 面向無連接：與面向連接相對，面向無連接是指通信雙方不需要事先建立通信線路，而是把每個帶有目的地址的報文分組送到線路上，由系統自主選定線路進行傳輸。由於面向無連接不需要在通信雙方進行數據傳輸前建立虛擬連接線路，而維護連接的過程正是影響面向連接網絡的瓶頸所在，因此面向無連接的服務能做到高效率和實時性，但可靠性相對面向連接服務較低一些。
- TCP 協議就是一種面向連接的協議。雙方進行通信之前首先要建立一個會話（三次握手），確保消息的準確到達，如果有什麼問題能夠相互通知然後解決。舉個栗子：打電話；
面向無連接：是指通信雙方不需要事先建立一條通信線路，而是把每個帶有目的地址的包（報文分組）送到線路上，由系統自主選定路線進行傳輸。IP、UDP 協議就是一種無連接協議。舉個栗子，郵政系統是一個無連接的模式，寫信人寫好對方的地址和自己的姓名地址然後就交給郵遞公司了，至於到沒到達也不能即使確認，所以是不可靠的。
6. 三次握手
引用dreamispossible的原文鏈接：我覺得寫得不錯，略加修改改成符合自己思維的版本：
- 剛開始客戶端處於 closed 的狀態，服務端處於 listen 狀態。然後：
- 第一次握手：客戶端給服務端發一個 SYN 報文（即同步序列號報文），並指明客戶端的初始化序列號 ISN© 。此時客戶端處於 SYN_Send 狀態。
- 第二次握手：服務器收到客戶端的 SYN 報文之後，會以自己的 SYN 報文作爲應答，並且也是指定了自己的初始化序列號 ISN(s)，同時會把客戶端的 ISN + 1 作爲 ACK 的值，表示自己已經收到了客戶端的 SYN 報文，此時服務器處於 SYN_REVD 的狀態。
- 第三次握手：客戶端收到 SYN 報文之後，會發送一個 ACK 報文，當然，也是一樣把服務器的 ISN + 1 作爲 ACK 的值，表示已經收到了服務端的 SYN 報文，此時客戶端處於 establised 狀態。
- 服務器收到 ACK 報文之後，也處於 establised 狀態，此時，雙方以建立起了鏈接。
- 在 socket 編程中，客戶端執行 connect() 時，將觸發三次握手。
7. 爲什麼需要三次握手，兩次不行嗎？
- 弄清楚這個問題，首先需要搞明白三次握手的目的是什麼，能不能只用兩次握手來達到同樣的目的。
- 第一次握手：客戶端發送網絡包，服務端收到了。這樣服務器就能得出結論：客戶端的發送能力、服務器端的接收能力是正常的。
- 第二次握手：服務端發包，客戶端收到了。這樣客戶的就能得出結論：服務端的接收、發送能力，客戶端的接收、發送能力是正常的。不過，此時的服務器並不能確認客戶端的接收能力是否正常。
- 第三次握手：客戶端發包，服務器收到了。這樣服務端就能得到結論：客戶端的接收、發送能力正常，自己的發送、接收能力也正常。
- 故：需要三次握手才能確認雙方的接收與發送能力是否正常！
- 試想一下，如果是用兩次握手，則會出現以下情況： 客戶端發送連接請求，但因連接請求報文丟失而未收到確認，於是客戶端再次發送一次連接請求。後來收到了確認，建立了連接。數據傳輸完畢後，就釋放了連接，客戶端共發出了兩個連接請求報文，其中第一個丟失，第二個到達了服務端，但第一個丟失的報文段只是在某些網絡結點長時間滯留了，延誤到連接釋放以後的某個時間纔到達服務端，此時服務端誤認爲客戶端又發來了一次新的連接請求，於是就向客戶端發出確認報文段，同意建立連接，不採用三次握手，只要服務端發出確認，新的連接就已經建立了。而此時客戶端忽略了服務端發來的確認包，也不發送數據，則服務端一直等待客戶端發送數據，浪費服務器資源。
- 三次握手的作用除了確認雙方的接受能力、發送能力是否正常之外，還有：
- 指定自己的初始化序列號，爲後面的可靠傳送做準備。
- 如果是 https 協議的話，三次握手這個過程，還會進行數字證書的驗證以及加密密鑰的生成。
8. 半連接隊列與全連接隊列：
- 服務器第一次收到客戶端的 SYN 之後，就會處於 SYN_RCVD 狀態，此時雙方還沒有完全建立起連接，服務器會把此種狀態下的請求連接放入一個隊列中，此隊列稱之爲半連接隊列。
- 與之對應，全連接隊列，就是已經完成了三次握手，建立起的連接被放入的隊列。如果隊列滿了，就可能會出現丟包現象。
- 服務器發送完 SYN_ACK 後，如果未收到客戶端確認包，服務端進行首次重傳；等待一段時間仍未收到確認包，則進行第二次重傳；如果重傳次數超過系統規定的最大重傳次數，系統將該連接信息從半連接隊列中刪除。
注意：每次重傳所等待的時間不一定相同，一般會是指數增長，如1s、2s、4s、8s …
9. 關於 ISN （Initial Sequence Number）是否是固定的：
- ISN 不是固定的。當一端爲建立連接而發送它的 SYN 報文時，它爲連接選擇一個初始序號。ISN 隨時間而變化，因此每個連接都將具有不同的 ISN。
- ISN 可以看作是一個 32bit 的計數器，每 4ms 加 1。這樣選擇序號的目的在於防止在網絡中被延遲的分組在以後又被傳送，而導致某個連接的一方對它做錯誤的解釋。
- 三次握手中的一個重要功能是客戶端和服務端交換 ISN(Initial Sequence Number)，以便讓對方知道接下來接收數據時如何按序列號組裝數據。如果 ISN 是固定的，攻擊者很容易猜出後續的確認號，因此 ISN 是動態生成的。
10. 三次握手過程中可以攜帶數據嗎？
- 第三次握手可以攜帶數據。但前兩次是不可以的。
- 試想一下，假如第一次可以攜帶數據，如果有人要惡意攻擊服務器，那他每次都在第一次握手中的 SYN 報文中放入大量的數據。因爲攻擊者根本不關心服務器的接收、發送能力是否正常，然後瘋狂重發 SYN 報文，這會讓服務器花費大量時間和內容空間來接收報文。
- 也就是說，第一次握手不可以放數據，其中一個最簡單的原因就是會讓服務器更容易收到攻擊。而第三次握手時，客戶端已經處於 ESTABLISHED 狀態，對客戶端來說，連接已經建立了，也確認服務端的接收、發送能力正常，所以能攜帶數據。
11. SYN攻擊是什麼？
- 服務器端的資源分配是在二次握手時分配的，而客戶端的資源是在完成三次握手時分配的，所以服務器容易收到 SYN 泛洪攻擊。
- SYN 攻擊就是客戶端在短時間內僞造大量不存在的 IP 地址，並向服務器不斷地發送 SYN 包，服務端則回覆確認包，並等待客戶端確認。由於源地址不存在，因此服務端需要不斷重發直至超時，這些僞造的 SYN 包將長時間佔用未連接隊列，導致正常的 SYN 請求因爲隊列滿而被丟棄，從而引起網絡擁塞甚至系統癱瘓。
- SYN 攻擊是一種典型 DoS/DDoS 的攻擊。
- 檢測 SYN 攻擊非常方便，當你在服務器上看到大量的半連接狀態時，特別是源 IP 地址是隨機的，基本上可以斷定這是一次 SYN 攻擊。在 Linux/Unix 上可以使用系統自帶的 netstats 命令來檢測 SYN 攻擊：
netstats -n -p TCP | grep SYN_RECV
12. 四次揮手
- TCP 連接的拆除需要發送四個包，因此稱爲四次揮手，客戶端或服務器均可主動發起揮手動作。
- 剛開始雙方都處於 ESTABLISHED 狀態，假如是客戶端先發起關閉請求，四次揮手的過程如下：
- 第一次揮手：客戶端發送一個 FIN 報文，報文中會指定一個序列號。此時客戶端處於 FIN_WAIT1 狀態；
- 即發出連接釋放報文段（FIN=1，序號seq=u），並停止再發送數據，主動關閉 TCP 連接，進入 FIN_WAIT1 (終止等待1)狀態，等待服務端的確認。
- 第二次揮手：服務端收到FIN包之後，會發送ACK報文，且把客戶端的序列號值+1 作爲ACK報文序列號值，表明已經收到客戶端的報文了，此時服務端處於CLOSE_WAIT狀態；
- 即服務端收到連接釋放的報文段後，立即發出確認報文段（ACK=1，確認號ack=u+1，序號seq=v），服務端進入 CLOSE_WAIT(關閉等待)狀態，此時的 TCP 處於半關閉狀態，客戶端到服務端的連接釋放。客戶端收到服務端的確認後，進入 FIN_WAIT2(終止等待2)狀態，等待服務端發出的連接釋放報文段；
- 第三次揮手：如果服務端也想斷開連接，和客戶端的第一次揮手一樣，發送 FIN 報文，且指定一個序列號。此時服務端處於 LAST_ACK 狀態。
- 即服務端沒有要向客戶端發送的數據，服務端發出連接釋放的報文段（FIN=1，ACK=1，序號seq=w，確認號ack=u+1），服務端進入 LAST_ACK(最後確認)狀態，等待客戶端確認。
- 第四次揮手：客戶端收到 FIN 之後，一樣發送一個 ACK 報文作爲應答，且把服務端的序列號值+1 作爲自己的 ACK 報文的序列號值，此時客戶端處於 TIME_WAIT 狀態，需要過一陣子纔會進入 CLOSED 狀態，爲了確保服務端收到自己的 ACK 報文。服務端收到 ACK 報文之後，就會關閉連接，也進入 CLOSED 狀態。
- 即客戶端收到服務端的連接釋放報文段後，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），客戶端進入 TIME_WAIT(時間等待)狀態。此時 TCP 未釋放掉，需要經過時間等待計數器設置的時間 2MSL（報文最大生存時間）後，客戶端纔會進入 CLOSED 狀態。
- 在 socket 編程中，任何一方執行 close() 操作即可產生回收操作。
13. MSL （報文最大生存時間）Maximum Segment Lifetime
- MSL：最長報文段壽命，它是任何報文在網絡上存在的最長時間，超過這個時間的報文將被丟棄。
- 這裏特別需要主要的就是 TIME_WAIT 這個狀態了，這個是面試的高頻考點，就是要理解，爲什麼客戶端發送 ACK 之後不直接關閉，而是要等一陣子才關閉。這其中的原因就是，要確保服務器是否已經收到了我們的 ACK 報文，如果沒有收到的話，服務器會重新發 FIN 報文給客戶端，客戶端再次收到 ACK 報文之後，就知道之前的 ACK 報文丟失了，然後再次發送 ACK 報文。
- 至於 TIME_WAIT 持續的時間至少是一個報文的來回時間。一般會設置一個計時，如果過了這個計時沒有再次收到 FIN 報文，則代表對方成功就是 ACK 報文，此時處於 CLOSED 狀態。
14. 揮手爲什麼需要四次？
- 前兩次揮手是爲了斷開 client 至 server 的連接，後兩次揮手是爲了斷開 server 至 client 的連接，如果沒有第四次揮手，會出現如下狀況：
- server 發送 FIN 數據包並攜帶 ACK 至 client 之後直接斷開連接，如果 client 沒有收到這個 FIN 數據包，那麼 client 會一直處於等待關閉狀態，這是爲了確保 TCP 協議是面向連接安全有保證的。
- 上面解釋了爲什麼不是三次揮手，同理，兩次揮手也是不安全的。不能保證 server 與 client 都能正確關閉連接釋放資源，而不會造成資源浪費。
15. 控制擁塞：
擁塞控制與流量控制的區別：
- 擁塞控制是防止過多的數據注入到網絡中，可以使網絡中的路由器或鏈路不致過載，是一個全局性的過程。流量控制是點對點通信量的控制，是一個端到端的問題，主要就是抑制發送端發送數據的速率，以便接收端來得及接收。
擁塞的標誌：
- ①：重傳計時器超時；
- ②：接收到三個重複確認.
擁塞控制算法：
- 擁塞窗口的大小取決於網絡的擁塞程度，並且在動態地變化，發送方讓自己的發送窗口等於擁塞窗口。發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就可以再增大一些，以便把更多的分組發送出去，這樣就可以提高網絡的利用率，但只要網絡出現擁塞或可能出現擁塞，就必須把窗口減小一些，以減少注入到網絡中的分組數，以便緩解網絡出現的擁塞。
- 慢開始算法思想：當主機開始發送數據時，由於並不清楚網絡的負荷情況，如果立即把大量數據字節注入到網絡，那麼就有可能引起網絡發生擁塞，所以由小到大逐漸增大發送窗口，也就是由小到大逐漸增大擁塞窗口數值，試探一下網絡的擁塞情況。慢開始規定，在發送方每收到一個新的報文段的確認後，擁塞窗口的值就增大 1，剛開始我們先設置擁塞窗口值爲 1，發送方收到一個新的確認報文之後，cwnd 變爲 2，發送方接收到兩個新的確認報文之後 cwnd 加 2 變成 4。即擁塞窗口的增長每次都是收到確認報文段數量的 2 倍。爲了防止擁塞窗口增長多大引起網絡阻塞，爲其設置了一個慢啓動門限，當到達門限時，就進入到擁塞避免階段。
- 擁塞避免算法的思路：不再以指數形式增長擁塞窗口，而是每經過一個往返時間 RTT 就將發送方的擁塞窗口 + 1，使其增長緩慢，按照線性方式增長，如果發生網絡擁塞，比如丟包時，就將慢啓動門限設爲原來的一半，然後將擁塞窗口設置爲 1，開始執行慢啓動算法。
- 快速重傳算法思想：快速重傳要求接收方不要等待自己發送數據時才進行捎帶確認，而是要立即發送確認，即使收到了失序的報文段也要立即發出對已收到的報文段的重複確認。快速重傳規定，發送方只要一連接收到 3 個重複確認，就知道接收方確實沒有收到該報文段，因而應當立即進行重傳，這樣就不會出現超時，發送方也就不會誤認爲出現了網絡擁塞。使用快速重傳可以使整個網絡的吞吐量提高約 20%。快速重傳後進入快速恢復。
- 快速恢復的思想：將慢啓動門限值設置爲原來的一半，然後將擁塞窗口設置爲現在的慢啓動的門限值，不再執行慢啓動而是直接進入擁塞避免階段。使發送窗口成線性方式增長。+ + 也有的快速恢復實現是把快速恢復時的擁塞窗口 cwnd 值再增大一些（即 3 個報文段長度），即等於新的門限值 + 3 個報文段長度。這樣做的理由是，既然發送方收到 3 個重複的確認，就表明 3 個分組已經離開了網絡。這 3 個分組不再消耗網絡的資源，而是停留在接收方的緩衝區種（接收方發送出了 3 個重複確認就證明了這個事實）。可見現在網絡中並不是堆積了分組，而是減少了 3 個分組。因此可以適當的把擁塞窗口擴大些。
16. 什麼是網絡套接字（Socket）
- TCP 用主機的 IP 地址加上主機上的端口號作爲 TCP 連接的端點，這種端點就叫做套接字 (socket) 或插口。
- 套接字用(IP 地址:端口號)表示。
- 它是網絡通信過程中端點的抽象表示，包含進行網絡通信必需的五種信息：連接使用的協議，本地主機的 IP 地址，本地進程的協議端口，遠地主機的 IP 地址，遠地進程的協議端口。
17. 訪問一個網頁的過程
孤獨煙的天龍八步
①：DNS 域名系統解析域名得到 IP
- 正常情況下，瀏覽器會緩存 DNS 一段時間，一般 2 分鐘到 30 分鐘不等。如果有緩存，直接返回 IP。
- 緩存中如果沒有查到 IP，瀏覽器會做系統調用，讀取主機的 hosts 文件，如果找到，直接返回 IP。
- hosts 文件裏面還是沒有找到，則直接去路由器中尋找 DNS 緩存，一般這個時候都能找到對應的 IP。
- 如果還是沒有找到，ISP （網絡運營服務商）的 DNS 服務器就開始從根域名服務器開始遞歸搜索，從 .com 頂級域名服務器開始，一直到 baidu 的域名服務器。
- 這個時候，瀏覽器就獲取到了對應的 IP。在解析的過程中，常常會解析出不同的 IP，這是根據不同的用戶，不同的網絡供應商，所在的地域，等等等等進行計算給出的最優的 IP 地址。
②：發起 TCP 連接：
- 拿到域名對應的 IP 地址之後，瀏覽器會以一個隨機端口（1024 < 端口 < 65535）向服務器的 WEB 程序（常用的有httpd,nginx等）80 端口發起 TCP 的連接請求。這個連接請求到達服務器端後（這中間通過各種路由設備，局域網內除外），進入到網卡，然後是進入到內核的 TCP/IP 協議棧（用於識別該連接請求，解封包，一層一層的剝開），還有可能要經過 Netfilter 防火牆（屬於內核的模塊）的過濾，最終到達 WEB 程序，最終建立了 TCP/IP 的連接。
③：向 IP 地址發送HTTP請求
④：服務器處理請求
⑤：返回響應結果
⑥：關閉TCP連接
⑦：瀏覽器解析HTML
⑧：瀏覽器佈局渲染
18. HTTP 和 HTTPS 的區別
- HTTP 是協議時超文本傳輸協議，HTTPS 是安全的超文本傳輸協議，是安全版的 HTTP 協議，使用安全套接字層 (SSL) 進行信息交換。
- HTTPS 協議主要針對解決 HTTP 協議以下不足：
①：通信使用明文（不加密），內容可能會被竊聽
②：不驗證通信方身份，應此可能遭遇僞裝
③：無法證明報文的完整性（即準確性），所以可能已遭篡改
即： HTTP + 加密 + 認證 + 完整性保護 = HTTPS - HTTP 端口 80，HTTPS 端口 443
- HTTPS 採用對稱加密
- SSL位於應用層於傳輸層 TCP 之間，原本數據由應用層直接交由傳輸層處理，現在會經過 SSL 加密再進行傳輸。
- HTTPS 也不是絕對安全的，針對 SSL 的中間人攻擊方式主要有兩類，分別是 SSL 劫持攻擊和 SSL 剝離攻擊。SSL 劫持攻擊就是 SSL 證書欺騙攻擊，將自己接入到客戶端和目標網站之間； 在傳輸過程中僞造服務器的證書，將服務器的公鑰替換成自己的公鑰。
19. 交換機與路由器的區別
4. 常用的 http 有哪些方法
答：
- GET： 用於請求訪問已經被 URI（統一資源標識符）識別的資源，可以通過 URL 傳參給服務器。
- POST：用於傳輸信息給服務器，主要功能與 GET 方法類似，但一般推薦使用 POST 方式。
- PUT： 傳輸文件，報文主體中包含文件內容，保存到對應 URI 位置。
- HEAD： 獲得報文首部，與 GET 方法類似，只是不返回報文主體，一般用於驗證 URI 是否有效。
- DELETE：刪除文件，與 PUT 方法相反，刪除對應 URI 位置的文件。
- OPTIONS：查詢相應 URI 支持的 HTTP 方法。
5. get 與 post 區別
答：
6. http 協議及特點
答：
7. http 狀態碼
答：
8. http2.0 (與 http1.1 有什麼區別)
答：
9. https (結構，爲什麼安全？)
答：
11. 緩存 (expires/cache-control/…)
答：
12. 持久連接 (keep-alive)
答：
13. cookies
答：
14. web 安全 (jsonp/xss 原理與防禦)
答：