來源：juejin.im/post/5ad4094e6fb9a028d7011069

TCP

要說http就繞不開tcp，TCP協議對應于傳輸層，而HTTP協議對應于應用層，從本質上來說，二者沒有可比性。但是，http是基于tcp協議的。

TCP/IP 協議分層模型

物理層將二進制的0和1和電壓高低，光的閃滅和電波的強弱信號進行轉換
鏈路層代表驅動
網絡層
- 使用 IP 協議，IP 協議基于 IP 轉發分包數據
- IP 協議是個不可靠協議，不會重發
- IP 協議發送失敗會使用ICMP 協議通知失敗
- ARP 解析 IP 中的 mac 地址，MAC 地址由網卡出廠提供
- IP 還隱含鏈路層的功能，不管雙方底層的鏈路層是啥，都能通信
傳輸層
- TCP 協議面向有連接，能正確處理丟包，傳輸順序錯亂的問題，但是為了建立與斷開連接，需要至少7次的發包收包，資源浪費
- UDP 面向無連接，不管對方有沒有收到，如果要得到通知，需要通過應用層
- 通用的 TCP 和 UDP 協議
會話層以上分層
- TCP/IP 分層中，會話層，表示層，應用層集中在一起
- 網絡管理通過 SNMP 協議

劃重點了啊（面試最常問的啊）

TCP三次握手和四次揮手？

被問爛了的問題了，這里不詳細講了，

三次握手：

客戶端–發送帶有SYN標志的數據包–一次握手–服務端
服務端–發送帶有SYN/ACK標志的數據包–二次握手–客戶端
客戶端–發送帶有帶有ACK標志的數據包–三次握手–服務端

四次揮手：

客戶端-發送一個FIN，用來關閉客戶端到服務器的數據傳送
服務器-收到這個FIN，它發回一個ACK，確認序號為收到的序號加1 。和SYN一樣，一個FIN將占用一個序號
服務器-關閉與客戶端的連接，發送一個FIN給客戶端
客戶端-發回ACK報文確認，并將確認序號設置為收到序號加1

還不懂的童鞋，去找別人的文章好好看看！

TCP和UDP的區別？

仔細閱讀上面傳輸層里寫的內容，懂了嗎？（不懂？不懂背下來啊，混蛋！）

我們微信聊天時候經常會有這種情況。

是不是感同身受，這種情況就是對方用了TCP協議來聊天，要經過--在嗎？--在--巴拉巴拉，才能成功的傳遞信息。而如果對方使用UDP，則會有事直接說，不管我收沒收到。（以后找我請用UDP協議，著急直接打電話！）

HTTP

Http協議是建立在TCP協議基礎之上的，當瀏覽器需要從服務器獲取網頁數據的時候，會發出一次Http請求。Http會通過TCP建立起一個到服務器的連接通道，當本次請求需要的數據完畢后，Http會立即將TCP連接斷開，這個過程是很短的。所以Http連接是一種短連接，是一種無狀態的連接。

所謂的無狀態，是指瀏覽器每次向服務器發起請求的時候，不是通過一個連接，而是每次都建立一個新的連接。如果是一個連接的話，服務器進程中就能保持住這個連接并且在內存中記住一些信息狀態。而每次請求結束后，連接就關閉，相關的內容就釋放了，所以記不住任何狀態，成為無狀態連接。

http傳輸流

發送端在層與層間傳輸數據時，沒經過一層都會被加上首部信息，接收端每經過一層都會刪除一條首部

又來劃重點了啊

HTTP的英文全稱？

開玩笑的，這個顯然不是重點，但是不排除有人會去問，還是要知道的：超文本傳輸協議（HyperText Transfer Protocol）

狀態碼？

狀態碼就那些，常用的記住就行了：

2XX 成功

200 OK，表示從客戶端發來的請求在服務器端被正確處理
204 No content，表示請求成功，但響應報文不含實體的主體部分
206 Partial Content，進行范圍請求

3XX 重定向

301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
302 found，臨時性重定向，表示資源臨時被分配了新的 URL
303 see other，表示資源存在著另一個 URL，應使用 GET 方法定向獲取資源
304 not modified，表示服務器允許訪問資源，但因發生請求未滿足條件的情況
307 temporary redirect，臨時重定向，和302含義相同

4XX 客戶端錯誤

400 bad request，請求報文存在語法錯誤
401 unauthorized，表示發送的請求需要有通過 HTTP 認證的認證信息
403 forbidden，表示對請求資源的訪問被服務器拒絕
404 not found，表示在服務器上沒有找到請求的資源

5XX 服務器錯誤

500 internal sever error，表示服務器端在執行請求時發生了錯誤
503 service unavailable，表明服務器暫時處于超負載或正在停機維護，無法處理請求

HTTP協議格式？

HTTP的請求和響應的消息協議是一樣的，分為三個部分，起始行、消息頭和消息體。這三個部分以CRLF作為分隔符。最后一個消息頭有兩個CRLF，用來表示消息頭部的結束。

HTTP請求的起始行稱為請求行，形如GET /index.html HTTP/1.1

HTTP響應的起始行稱為狀態行，形如200 ok

消息頭部有很多鍵值對組成，多個鍵值對之間使用CRLF作為分隔符，也可以完全沒有鍵值對。形如Content-Encoding: gzip 消息體是一個字符串，字符串的長度是由消息頭部的Content-Length鍵指定的。如果沒有Content-Length字段說明沒有消息體，譬如GET請求就是沒有消息體的，POST請求的消息體一般用來放置表單數據。GET請求的響應返回的頁面內容也是放在消息體里面的。我們平時調用API返回的JSON內容都是放在消息體里面的。