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採用持續連線。所謂持續連線就是伺服器在傳送響應後仍然在一段時間內保持這條連線。使得後序的請求和響應報文都在這條連線上進行。