作為web開發人員，你必須要知道的問題！ （持續更新）

標籤：mtu   空行   策略   recv   文本   配置   理論   forbidden   基於   

GET 和 POST 的區別

 

GET請注意，查詢字串（成對的名稱和數值）是在 GET 請求的 URL 中發送的：/test/demo_form.asp?name1=value1&name2=value2

1. GET 請求可被緩衝

2. GET 請求保留在瀏覽器記錄中

3. GET 請求可被收藏為書籤

4. GET 請求不應在處理敏感性資料時使用

5. GET 請求有長度限制

6. GET 請求只應當用於取回資料POST 方法（POST）請注意，查詢字串（成對的名稱和數值）是在 POST 請求的 HTTP 訊息主體中發送的：POST /test/demo_form.asp HTTP/1.1Host: w3schools.comname1=value1&name2=value2

7. POST 請求不會被緩衝

8. POST 請求不會保留在瀏覽器記錄中

9. POST 不能被收藏為書籤

10. POST 請求對資料長度沒有要求

dns使用的協議

 

既使用TCP又使用UDP

首先瞭解一下TCP與UDP傳送位元組的長度限制：

 

UDP報文的最大長度為512位元組，而TCP則允許報文長度超過512位元組。當DNS查詢超過512位元組時，協議的TC標誌出現刪除標誌，這時則使用TCP發送。通常傳統的UDP報文一般不會大於512位元組。

 

地區傳送時使用TCP，主要有一下兩點考慮：

 

1. 輔網域名稱伺服器會定時（一般時3小時）向主網域名稱伺服器進行查詢以便瞭解資料是否有變動。如有變動，則會執行一次地區傳送，進行資料同步。地區傳送將使用TCP而不是UDP，因為資料同步傳送的資料量比一個請求和應答的資料量要多得多。

2. TCP是一種可靠的串連，保證了資料的準確性。

    

網域名稱解析時使用UDP協議：

 

用戶端向DNS伺服器查詢網域名稱，一般返回的內容都不超過512位元組，用UDP傳輸即可。不用經過TCP三向交握，這樣DNS伺服器負載更低，響應更快。雖然從理論上說，用戶端也可以指定向DNS伺服器查詢的時候使用TCP，但事實上，很多DNS伺服器進行配置的時候，僅支援UDP查詢包。

等冪

 

一個等冪操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。等冪函數，或等冪方法，是指可以使用相同參數重複執行，並能獲得相同結果的函數。這些函數不會影響系統狀態，也不用擔心重複執行會對系統造成改變。例如，“getUsername()和setTrue()”函數就是一個等冪函數.

Cookies和session區別

1. Cookies是一種能夠讓網站伺服器把少量資料儲存到用戶端的硬碟或記憶體，或是從用戶端的硬碟讀取資料的一種技術。Cookies是當你瀏覽某網站時，由Web伺服器置於你硬碟上的一個非常小的文字檔，它可以記錄你的使用者ID、密碼、瀏覽過的網頁、停留的時間等資訊。session: 當使用者請求來自應用程式的 Web 頁時，如果該使用者還沒有會話，則 Web 服務器將自動建立一個 Session 對象。當會話到期或被放棄後，伺服器將終止該會話。cookie機制：採用的是在用戶端保持狀態的方案，而session機制採用的是在服務端保持狀態的方案。同時我們看到由於伺服器端保持狀態的方案在用戶端也需要儲存一個標識，所以session機制可能需要藉助cookie機制來達到儲存標識的目的。

2. Session是伺服器用來跟蹤使用者的一種手段，每個Session都有一個唯一標識：session ID。當伺服器建立了Session時，給用戶端發送的響應報文包含了Set-cookie欄位，其中有一個名為sid的索引值對，這個索引值Session ID。用戶端收到後就把Cookie儲存瀏覽器，並且之後發送的請求報表都包含SessionID。HTTP就是通過Session和Cookie這兩個發送一起合作來實現跟蹤使用者狀態，Session用於服務端，Cookie用於用戶端

TCP粘包和拆包產生的原因

1. 應用程式寫入資料的位元組大小大於通訊端發送緩衝區的大小

2. 進行MSS大小的TCP分段。MSS是最大報文段長度的縮寫。MSS是TCP報文段中的資料欄位的最大長度。資料欄位加上TCP首部才等於整個的TCP報文段。所以MSS並不是TCP報文段的最大長度，而是：MSS=TCP報文段長度-TCP首部長度

3. 乙太網路的payload大於MTU進行IP分區。MTU指：一種通訊協定的某一層上面所能通過的最大資料包大小。如果IP層有一個資料包要傳，而且資料的長度比鏈路層的MTU大，那麼IP層就會進行分區，把資料包分成托乾片，讓每一片都不超過MTU。注意，IP分區可以發生在原始發送端主機上，也可以發生在中間路由器上。

TCP粘包和拆包的解決方案策略

1. 訊息定長。例如100位元組。

2. 在包尾部增加斷行符號或者空格符等特殊字元進行分割，典型的如FTP協議

3. 將訊息分為訊息頭和訊息尾。

4. 其它複雜的協議，如RTMP協議等。

三向交握

 

第一次握手：建立串連時，用戶端發送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；

第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；

第三向交握：用戶端收到伺服器的SYN＋ACK包，向伺服器發送確認包ACK(ack=k+1)，此包發送完畢，用戶端和伺服器進入ESTABLISHED狀態，完成三向交握。

完成三向交握，用戶端與伺服器開始傳送資料

四次揮手

1. 用戶端先發送FIN，進入FIN_WAIT1狀態

2. 服務端收到FIN，發送ACK，進入CLOSE_WAIT狀態，用戶端收到這個ACK，進入FIN_WAIT2狀態

3. 服務端發送FIN，進入LAST_ACK狀態

4. 用戶端收到FIN，發送ACK，進入TIME_WAIT狀態，服務端收到ACK，進入CLOSE狀態

TIME_WAIT的狀態就是主動斷開的一方（這裡是用戶端），發送完最後一次ACK之後進入的狀態。並且期間還挺長的。用戶端TIME_WAIT持續2倍MSL時間長度，在linux體系中大概是60s，轉換成CLOSE狀態

TIME_WAIT

TIME_WAIT 是主動關閉連結時形成的，等待2MSL時間，約4分鐘。主要是防止最後一個ACK丟失。 由於TIME_WAIT 的時間會非常長，因此server端應盡量減少主動關閉串連

CLOSE_WAIT

CLOSE_WAIT是被動關閉串連是形成的。根據TCP狀態機器，伺服器端收到用戶端發送的FIN，則按照TCP實現發送ACK，因此進入CLOSE_WAIT狀態。但如果伺服器端不執行close()，就不能由CLOSE_WAIT遷移到LAST_ACK，則系統中會存在很多CLOSE_WAIT狀態的串連。此時，可能是系統忙於處理讀、寫操作，而未將已收到FIN的串連，進行close。此時，recv/read已收到FIN的串連socket，會返回0。

為什麼需要 TIME_WAIT 狀態？

假設最終的ACK丟失，server將重發FIN，client必須維護TCP狀態資訊以便可以重發最終的ACK，否則會發送RST，結果server認為發生錯誤。TCP實現必須可靠地終止串連的兩個方向(全雙工系統關閉)，client必須進入 TIME_WAIT 狀態，因為client可能面 臨重發最終ACK的情形。

為什麼 TIME_WAIT 狀態需要保持 2MSL 這麼長的時間？

如果 TIME_WAIT 狀態保持時間不足夠長(比如小於2MSL)，第一個串連就正常終止了。第二個擁有相同相關五元組的串連出現，而第一個串連的重複報文到達，幹擾了第二個串連。TCP實現必須防止某個串連的重複報文在串連終止後出現，所以讓TIME_WAIT狀態保持時間足夠長(2MSL)，串連相應方向上的TCP報文要麼完全響應完畢，要麼被 丟棄。建立第二個串連的時候，不會混淆。

TIME_WAIT 和CLOSE_WAIT狀態socket過多

如果伺服器出了異常，百分之八九十都是下面兩種情況：

1.伺服器保持了大量TIME_WAIT狀態

2.伺服器保持了大量CLOSE_WAIT狀態，簡單來說CLOSE_WAIT數目過大是由於被動關閉串連處理不當導致的。

一次完整的HTTP請求過程

 

網域名稱解析 --> 發起TCP的3次握手 --> 建立TCP串連後發起http請求 --> 伺服器響應http請求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給使用者

講一下長串連

 

一、基於http協議的長串連

 

在HTTP1.0和HTTP1.1協議中都有對長串連的支援。其中HTTP1.0需要在request中增加”Connection： keep-alive“ header才能夠支援，而HTTP1.1預設支援.

 

http1.0請求與服務端的互動過程:

1. 用戶端發出帶有包含一個header：”Connection： keep-alive“的請求

2. 服務端接收到這個請求後,根據http1.0和”Connection： keep-alive“判斷出這是一個長串連,就會在response的header中也增加”Connection： keep-alive“,同是不會關閉已建立的tcp串連.

3. 用戶端收到服務端的response後,發現其中包含”Connection： keep-alive“，就認為是一個長串連，不關閉這個串連。並用該串連再發送request.轉到a)，點擊這裡瞭解 http 1.0 vs 2.0 區別。

    

二、發心跳包。每隔幾秒就發一個資料包過去

TCP如何保證可靠傳輸？

1. 三向交握。

2. 將資料截斷為合理的長度。應用資料被分割成 TCP 認為最適合發送的資料區塊（按位元組編號，合理分區）

3. 逾時重發。當 TCP 發出一個段後，它啟動一個定時器，如果不能及時收到一個確認就重發

4. 對於收到的請求，給出確認響應

5. 校正出包有錯，丟棄報文段，不給出響應

6. 對失序資料進行重新排序，然後才交給應用程式層

7. 對於重複資料 ， 能夠丟棄重複資料

8. 流量控制。TCP 串連的每一方都有固定大小的緩衝空間。TCP 的接收端只允許另一端發送接收端緩衝區所能接納的資料。這將防止較快主機致使較慢主機的緩衝區溢位。

9. 擁塞控制。當網路擁塞時，減少資料的發送。

詳細介紹http

 

HTTP協議是Hyper Text Transfer Protocol（超文字傳輸通訊協定 (HTTP)）的縮寫,是用於從全球資訊網（WWW:World Wide Web ）伺服器傳輸超文本到本地瀏覽器的傳送協議。點擊這裡瞭解 http 1.0 vs 2.0 區別。

特點

1. 簡單快速：客戶向伺服器請求服務時，只需傳送要求方法和路徑。要求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的類型不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。

2. 靈活：HTTP允許傳輸任意類型的資料對象。正在傳輸的類型由Content-Type加以標記。

3. 無串連：不需連線的含義是限制每次串連只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即中斷連線。採用這種方式可以節省傳輸時間。

4. 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於交易處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次串連傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

5. 支援B/S及C/S模式。

請求訊息Request

1. 請求行，用來說明請求類型,要訪問的資源以及所使用的HTTP版本.

2. 要求標頭部，緊接著請求行（即第一行）之後的部分，用來說明伺服器要使用的附加資訊從第二行起為要求標頭部，HOST將指出請求的目的地.User-Agent,伺服器端和用戶端指令碼都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該資訊由你的瀏覽器來定義,並且在每個請求中自動發送等等

3. 空行，要求標頭部後面的空行是必須的

4. 請求資料也叫主體，可以添加任意的其他資料。

響應訊息Response

1. 狀態行，由HTTP協議版本號碼， 狀態代碼， 狀態訊息 三部分組成。

2. 訊息前序，用來說明用戶端要使用的一些附加資訊

3. 空行，訊息前序後面的空行是必須的

4. 響應本文，伺服器返回給用戶端的文本資訊。

狀態代碼

• 200 OK //用戶端請求成功

• 301 Moved Permanently //永久重新導向,使用網域名稱跳轉

• 302 Found // 臨時重新導向,未登陸的使用者訪問使用者中心重新導向到登入頁面

• 400 Bad Request //用戶端請求有語法錯誤，不能被伺服器所理解

• 401 Unauthorized //請求未經授權，這個狀態碼必須和WWW-Authenticate前序域一起使用

• 403 Forbidden //伺服器收到請求，但是拒絕提供服務

• 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL

• 500 Internal Server Error //伺服器發生不可預期的錯誤

• 503 Server Unavailable //伺服器當前不能處理用戶端的請求，一段時間後可能恢複正常

http的方法

1. get:用戶端向服務端發起請求，獲得資源。請求獲得URL處所在的資源。

2. post:向服務端提交新的請求欄位。請求URL的資源後添加新的資料。

3. head:請求擷取URL資源的響應報告，即獲得URL資源的頭部

4. patch：請求局部修改URL所在資源的資料項目

5. put：請求修改URL所在資源的資料元素。

6. delete：請求刪除url資源的資料

URI和URL的區別

 

URI，是uniform resource identifier，統一資源識別項，用來唯一的標識一個資源。Web上可用的每種資源如HTML文檔、映像、視頻片段、程式等都是一個來URI來定位的

URI一般由三部組成：

1. 訪問資源的命名機制

2. 存放資源的主機名稱

3. 資源自身的名稱，由路徑表示，著重強調於資源。

URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明了如何locate這個資源。URL是Internet上用來描述資訊資源的字串，主要用在各種WWW客戶程式和伺服器程式上，特別是著名的Mosaic。採用URL可以用一種統一的格式來描述各種資訊資源，包括檔案、伺服器的地址和目錄等。

URL一般由三部組成：

1. 協議(或稱為服務方式)

2. 存有該資源的主機IP地址(有時也包括連接埠號碼)

3. 主機資源的具體地址。如目錄和檔案名稱等

HTTPS和HTTP的區別

1. https協議需要到CA申請認證，一般免費認證很少，需要交費。

2. http是超文字傳輸通訊協定 (HTTP)，資訊是明文傳輸；https 則是具有安全性的ssl加密傳輸協 議。

3. http和https使用的是完全不同的串連方式，用的連接埠也不一樣，前者是80，後者是443。

4. http的串連很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路通訊協定，比http協議安全。

5. http預設使用80連接埠，https預設使用443連接埠

https是如何保證資料轉送的安全

 

https實際就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護航，主要用到對稱式加密、非對稱式加密、認證，等技術進行用戶端與伺服器的資料加密傳輸，最終達到保證整個通訊的安全性。點擊這裡弄懂 https 的 9 個問題。

SSL/TLS協議作用：

1. 認證使用者和伺服器，確保資料發送到正確的客戶機和伺服器；

2. 加密資料以防止資料中途被竊取；

3. 維護資料的完整性，確保資料在傳輸過程中不被改變。

作為web開發人員，你必須要知道的問題！ （持續更新）