TCP協議
1.OSI與TCP/IP各層的結構和功能，協議和作用。
OSI七層模型對應TCP/IP四層模型，只是分法不同而已。
應用層：提供應用層服務，文件傳輸(FTP)，電子郵件(SMTP)， 主要的協議還有HTTP（超文本傳輸協議），DNS，和telnet
表示層：用於數據格式化，代碼轉換，數據加密，沒有協議
會話層：解除或建立與別的接點的聯系，沒有協議
傳輸層：TCP UDP
網絡層： IP ICMP（ping主要實現）， OSPF(全局泛洪，主要用於IP選路)
數據鏈路層 ARP（地址解析協議，根據IP地址獲得MAC地址）
物理層：
按照TCP/IP分的話，就四層，挺好記的，應用層，傳輸層，網絡層還有不知道叫什么名字，主機到網絡層？（包含物理層和數據鏈路層）
2.TCP和UDP有什么區別？
TCP是傳輸控制協議，提供的是面向連接的，可靠地字節流服務。實際數據傳輸之前服務器和客戶端要進行三次握手，會話結束后結束連接。UDP是用戶數據報協議，是無連接的。因為無連接，而且沒有超時重發機制，所以UDP傳輸速度很快。主要用於視頻傳輸（但其實現在各大視頻商都是用HTTP協議，而HTTP是基於TCP），實時視頻。
TCP保證數據按序到達，提供流量控制和擁塞控制，在網絡擁堵的時候會減慢發送字節數，而UDP不管網絡是否擁堵。
TCP是連接的，所以服務是一對一服務，而UDP可以1對1，也可以1對多（多播），也可以多對多。
3.TCP 的三次握手與四次揮手過程，各個狀態名稱與含義， TIMEWAIT 的作用。 TCP 的三次握手過程？為什么會采用三次握手，若采用二次握手可以嗎？
假設A是客戶端，B是服務端。A首先向B發出連接請求報文段，這個時候首部中的同步位SYN=1，同時選擇一個初始的序號x。此時報文段不能攜帶數據。此時A進入到SYN_SENT(同步已發送)狀態。
B受到連接請求報文，同意建立連接，向A發出確認。確認報文中，SYN和ACK都置1，確認號是x+1,與此同時，自己選擇一個初始序號y,這個報文也不能攜帶數據。此時B進入SYN_RCVD（同步收到）狀態。
A收到B的確認后，還要給B確認。這時可以攜帶數據，A進入到ESTABLISHED狀態。這就是三次握手的過程。
那如果兩次握手會怎么樣呢？
就是A為什么還要發送一次確認。為了防止已經失效的連接請求報文又突然傳送到了B,而產生錯誤。假設一種異常，A發出的請求由於網絡阻塞沒有及時到達B，后又重傳請求，之后B響應了，且建立了連接，之后連接又釋放了。此時假設A發出的第一個請求到達B,B誤以為是A再次請求連接，B建立連接，如果采用兩次握手，此時連接建立，而A又不發送數據，浪費了B的資源。
TCP的四次揮手
數據傳輸結束后，通信雙方都可以釋放連接。現在A和B都處於ESTABLISHED狀態，A的應用進程向其TCP發出連接釋放報文段，主動關閉TCP連接。A進入FIN_WAIT1（終止等待1）狀態。然后B確認，B進入CLOSE_WAIT(關閉等待)狀態。此時TCP處於半關閉狀態，A已經沒有數據要發送了，如果B仍要發送數據，B仍然接收。A收到B的確認后，就進入FIN_WAIT2（終止等待2）狀態，等待B發出連接釋放報文。 如果B已經沒有向A發送的數據，則B發送請求釋放報文，B進入LAST_ACK（最后確認）階段，等待A的確認。A在收到B的請求后，要發出確認，然后進入TIME_WAIT（時間等待）狀態。此時，連接還未釋放，必須等待時間等待計時器設定的時間的2MSL后，A才進入CLOSED狀態。
為什么最后要等一個TIME_WAIT時間呢？一：為了保證最后一個ACK能夠到達B,防止丟失了，B重傳，A不能回復確認。二是為了防止之前提到的“已經失效的連接請求報文段“出現在連接中”。A發送完最后一個ACK，再經過時間2MSL，可以使本連接產生的所有請求報文從網絡中消失。
4.TCP擁塞控制
擁塞控制就是防止過多的數據注入到網絡中，這樣使得網絡中的路由器或者鏈路不至於過載。TCP擁塞控制方法主要包括：慢開始，擁塞避免，快重傳和快恢復。
慢開始是指發送方先設置cwnd=1，一次發送一個報文段，隨后每經過一個傳輸輪次，擁塞串口cwnd就加倍，其實增長並不慢，以指數形式增長。還要設定一個慢開始門限，當cwnd>門限值，改用擁塞避免算法。擁塞避免算法使cwnd按線性規律緩慢增長。當網絡發生延時，門限值減半，擁塞窗口執行慢開始算法。
之后又提出了快重傳和快恢復
當接收方收到失序的報文段，按照快重傳，需要盡快發送對未收到的報文段的重復確認。快恢復是指當擁塞串口達到門限值，不直接開啟慢啟動算法，而是快恢復，快恢復就是收到三個重復的確認（可看作是網絡已經擁塞了），此時並不執行慢開始算法，而是執行快恢復，就是新的門限值是原來的一半，直接進入擁塞避免階段。
5.滑動窗口協議和回退n針協議
發送方和接收方都維護一個數據幀序列，這個序列叫窗口。
發送方的窗口由接收方確定，目的在於控制發送速度，以免接受方緩存不夠大，而導致溢出。這其實屬於流量控制范疇。如圖，接收方告訴發送方，建議滑動窗口為6，（否則太大一次發送太大，我接收緩沖區太小，處理不過來），然后發送方可以一次發送6個數據幀，假設已經發送了4,5,6，但是沒收到關聯的ACK，7,8,9則等待發送，如果此時發送端收到4號ACK，則窗口向右收縮，此時窗口就“滑動”了
滑動窗口協議是理論，可以用的是后退n針協議。發送方一次發送比如說10個幀，前兩個針都返回了對應的ACK，數據幀2出現了錯誤，這時發送方被迫重新發送2-8這七個幀，這就是回退n幀協議。但是如果接收方已經接收到了3-8幀，只是丟失了2幀，全部重傳太浪費網絡條件了，所以有時候會選擇重傳丟失的的幀。這就是選擇重傳協議。
HTTP協議
HTTP報文結構
HTTP有兩類報文：
1）請求報文
2）響應報文
HTTP的請求報文和響應報文由三個部分組成。
1）開始行。用於區分是請求報文還是響應報文。在請求報文中的開始行叫做請求行，在響應報文中的開始行叫做狀態行
2）首部行，用於說明瀏覽器，服務器或報文主體的一些信息
3）實體主體
常見狀態碼和含義
狀態碼都是三位數字的，分為5大類共33種
1xx:表示通知消息，如請求收到了或者正在進行處理
2xx:表示成功，如接受或知道了
3xx:表示重定向，如要完成請求還要繼續采取行動
4xx:表示客戶的差錯，如請求由錯誤的語法或不能完成
5xx:表示服務器差錯
200：客戶端請求成功
400：bad request 客戶端請求錯誤
403：Forbidden 服務器收到請求，但是拒絕提供服務
404：Not found 請求資源不存在
500：Internal Server Error 服務器發生不可預期錯誤
503：服務器當前不能處理客戶端請求
HTTP請求的幾種類型
GET 請求讀取由URL所標志的信息
HEAD 請求讀取由URL所標志的信息的首部
POST 給服務器添加信息
PUT在指明的URL下存儲一個文檔
CONNECT 用於代理服務器
HTTP1.1和HTTP1.0的區別
HTTP1.0每請求一個文檔就要建立TCP連接，有幾次握手的時間花銷，如果一個主頁上有很多鏈接的對象需要依次進行連接，每次連接下載都要消耗這些開銷。
HTTP1.1采用持續連接。所謂持續連接就是服務器在發送響應后仍然在一段時間內保持這條連接。使得后序的請求和響應報文都在這條連接上進行。