GET 和 POST 的區(qū)別

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

GET 請求可被緩存

GET 請求保留在瀏覽器歷史記錄中

GET 請求可被收藏為書簽

GET 請求不應在處理敏感數(shù)據(jù)時使用

GET 請求有長度限制

GET 請求只應當用于取回數(shù)據(jù)POST 方法（POST）請注意，查詢字符串（名稱/值對）是在 POST 請求的 HTTP 消息主體中發(fā)送的：POST /test/demo_form.asp HTTP/1.1Host: w3schools.comname1=value1&name2=value2

POST 請求不會被緩存

POST 請求不會保留在瀏覽器歷史記錄中

POST 不能被收藏為書簽

POST 請求對數(shù)據(jù)長度沒有要求

dns使用的協(xié)議

既使用TCP又使用UDP

首先了解一下TCP與UDP傳送字節(jié)的長度限制：

UDP報文的最大長度為512字節(jié)，而TCP則允許報文長度超過512字節(jié)。當DNS查詢超過512字節(jié)時，協(xié)議的TC標志出現(xiàn)刪除標志，這時則使用TCP發(fā)送。通常傳統(tǒng)的UDP報文一般不會大于512字節(jié)。

區(qū)域傳送時使用TCP，主要有一下兩點考慮：

• 輔域名服務器會定時（一般時3小時）向主域名服務器進行查詢以便了解數(shù)據(jù)是否有變動。如有變動，則會執(zhí)行一次區(qū)域傳送，進行數(shù)據(jù)同步。區(qū)域傳送將使用TCP而不是UDP，因為數(shù)據(jù)同步傳送的數(shù)據(jù)量比一個請求和應答的數(shù)據(jù)量要多得多。
• TCP是一種可靠的連接，保證了數(shù)據(jù)的準確性。

域名解析時使用UDP協(xié)議：

客戶端向DNS服務器查詢域名，一般返回的內(nèi)容都不超過512字節(jié)，用UDP傳輸即可。不用經(jīng)過TCP三次握手，這樣DNS服務器負載更低，響應更快。雖然從理論上說，客戶端也可以指定向DNS服務器查詢的時候使用TCP，但事實上，很多DNS服務器進行配置的時候，僅支持UDP查詢包。

冪等

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

Cookies和session區(qū)別

• Cookies是一種能夠讓網(wǎng)站服務器把少量數(shù)據(jù)儲存到客戶端的硬盤或內(nèi)存，或是從客戶端的硬盤讀取數(shù)據(jù)的一種技術。Cookies是當你瀏覽某網(wǎng)站時，由Web服務器置于你硬盤上的一個非常小的文本文件，它可以記錄你的用戶ID、密碼、瀏覽過的網(wǎng)頁、停留的時間等信息。session: 當用戶請求來自應用程序的 Web 頁時，如果該用戶還沒有會話，則 Web 服務器將自動創(chuàng)建一個 Session 對象。當會話過期或被放棄后，服務器將終止該會話。cookie機制：采用的是在客戶端保持狀態(tài)的方案，而session機制采用的是在服務端保持狀態(tài)的方案。同時我們看到由于服務器端保持狀態(tài)的方案在客戶端也需要保存一個標識，所以session機制可能需要借助cookie機制來達到保存標識的目的。
• Session是服務器用來跟蹤用戶的一種手段，每個Session都有一個唯一標識：session ID。當服務器創(chuàng)建了Session時，給客戶端發(fā)送的響應報文包含了Set-cookie字段，其中有一個名為sid的鍵值對，這個鍵值Session ID。客戶端收到后就把Cookie保存瀏覽器，并且之后發(fā)送的請求報表都包含SessionID。HTTP就是通過Session和Cookie這兩個發(fā)送一起合作來實現(xiàn)跟蹤用戶狀態(tài)，Session用于服務端，Cookie用于客戶端

TCP粘包和拆包產(chǎn)生的原因

應用程序寫入數(shù)據(jù)的字節(jié)大小大于套接字發(fā)送緩沖區(qū)的大小

進行MSS大小的TCP分段。MSS是最大報文段長度的縮寫。MSS是TCP報文段中的數(shù)據(jù)字段的最大長度。數(shù)據(jù)字段加上TCP首部才等于整個的TCP報文段。所以MSS并不是TCP報文段的最大長度，而是：MSS=TCP報文段長度-TCP首部長度

以太網(wǎng)的payload大于MTU進行IP分片。MTU指：一種通信協(xié)議的某一層上面所能通過的最大數(shù)據(jù)包大小。如果IP層有一個數(shù)據(jù)包要傳，而且數(shù)據(jù)的長度比鏈路層的MTU大，那么IP層就會進行分片，把數(shù)據(jù)包分成托干片，讓每一片都不超過MTU。注意，IP分片可以發(fā)生在原始發(fā)送端主機上，也可以發(fā)生在中間路由器上。

TCP粘包和拆包的解決策略

消息定長。例如100字節(jié)。

在包尾部增加回車或者空格符等特殊字符進行分割，典型的如FTP協(xié)議

將消息分為消息頭和消息尾。

其它復雜的協(xié)議，如RTMP協(xié)議等。

三次握手

第一次握手：建立連接時，客戶端發(fā)送syn包(syn=j)到服務器，并進入SYN_SEND狀態(tài)，等待服務器確認；

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

第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發(fā)送確認包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務器進入ESTABLISHED狀態(tài)，完成三次握手。

完成三次握手，客戶端與服務器開始傳送數(shù)據(jù)

四次揮手

客戶端先發(fā)送FIN，進入FIN_WAIT1狀態(tài)

服務端收到FIN，發(fā)送ACK，進入CLOSE_WAIT狀態(tài)，客戶端收到這個ACK，進入FIN_WAIT2狀態(tài)

服務端發(fā)送FIN，進入LAST_ACK狀態(tài)

客戶端收到FIN，發(fā)送ACK，進入TIME_WAIT狀態(tài)，服務端收到ACK，進入CLOSE狀態(tài)

TIME_WAIT的狀態(tài)就是主動斷開的一方（這里是客戶端），發(fā)送完最后一次ACK之后進入的狀態(tài)。并且持續(xù)時間還挺長的。客戶端TIME_WAIT持續(xù)2倍MSL時長，在linux體系中大概是60s，轉換成CLOSE狀態(tài)

TIME_WAIT

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

CLOSE_WAIT

CLOSE_WAIT是被動關閉連接是形成的。根據(jù)TCP狀態(tài)機，服務器端收到客戶端發(fā)送的FIN，則按照TCP實現(xiàn)發(fā)送ACK，因此進入CLOSE_WAIT狀態(tài)。但如果服務器端不執(zhí)行close()，就不能由CLOSE_WAIT遷移到LAST_ACK，則系統(tǒng)中會存在很多CLOSE_WAIT狀態(tài)的連接。此時，可能是系統(tǒng)忙于處理讀、寫操作，而未將已收到FIN的連接，進行close。此時，recv/read已收到FIN的連接socket，會返回0。

為什么需要 TIME_WAIT 狀態(tài)？

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

為什么 TIME_WAIT 狀態(tài)需要保持 2MSL 這么長的時間？

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

TIME_WAIT 和CLOSE_WAIT狀態(tài)socket過多

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

1.服務器保持了大量TIME_WAIT狀態(tài)

2.服務器保持了大量CLOSE_WAIT狀態(tài)，簡單來說CLOSE_WAIT數(shù)目過大是由于被動關閉連接處理不當導致的。

一次完整的HTTP請求過程

域名解析 --> 發(fā)起TCP的3次握手 --> 建立TCP連接后發(fā)起http請求 --> 服務器響應http請求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，并請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現(xiàn)給用戶

講一下長連接

一、基于http協(xié)議的長連接

在HTTP1.0和HTTP1.1協(xié)議中都有對長連接的支持。其中HTTP1.0需要在request中增加”Connection： keep-alive“ header才能夠支持，而HTTP1.1默認支持.

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

客戶端發(fā)出帶有包含一個header：”Connection： keep-alive“的請求

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

客戶端收到服務端的response后,發(fā)現(xiàn)其中包含”Connection： keep-alive“，就認為是一個長連接，不關閉這個連接。并用該連接再發(fā)送request.轉到a)，點擊這里了解 http 1.0 vs 2.0 區(qū)別。

二、發(fā)心跳包。每隔幾秒就發(fā)一個數(shù)據(jù)包過去

TCP如何保證可靠傳輸？

三次握手。

將數(shù)據(jù)截斷為合理的長度。應用數(shù)據(jù)被分割成 TCP 認為最適合發(fā)送的數(shù)據(jù)塊（按字節(jié)編號，合理分片）

超時重發(fā)。當 TCP 發(fā)出一個段后，它啟動一個定時器，如果不能及時收到一個確認就重發(fā)

對于收到的請求，給出確認響應

校驗出包有錯，丟棄報文段，不給出響應

對失序數(shù)據(jù)進行重新排序，然后才交給應用層

對于重復數(shù)據(jù) ， 能夠丟棄重復數(shù)據(jù)

流量控制。TCP 連接的每一方都有固定大小的緩沖空間。TCP 的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)。這將防止較快主機致使較慢主機的緩沖區(qū)溢出。

擁塞控制。當網(wǎng)絡擁塞時，減少數(shù)據(jù)的發(fā)送。

詳細介紹http

HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫,是用于從萬維網(wǎng)（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協(xié)議。點擊這里了解 http 1.0 vs 2.0 區(qū)別。

特點

• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務器的程序規(guī)模小，因而通信速度很快。
• 靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標記。
• 無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。
• 無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
• 支持B/S及C/S模式。

請求消息Request

1. 請求行，用來說明請求類型,要訪問的資源以及所使用的HTTP版本.
2. 請求頭部，緊接著請求行（即第一行）之后的部分，用來說明服務器要使用的附加信息從第二行起為請求頭部，HOST將指出請求的目的地.User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該信息由你的瀏覽器來定義,并且在每個請求中自動發(fā)送等等
3. 空行，請求頭部后面的空行是必須的
4. 請求數(shù)據(jù)也叫主體，可以添加任意的其他數(shù)據(jù)。

響應消息Response

1. 狀態(tài)行，由HTTP協(xié)議版本號， 狀態(tài)碼， 狀態(tài)消息 三部分組成。
2. 消息報頭，用來說明客戶端要使用的一些附加信息
3. 空行，消息報頭后面的空行是必須的
4. 響應正文，服務器返回給客戶端的文本信息。

狀態(tài)碼

• 200 OK //客戶端請求成功
• 301 Moved Permanently //永久重定向,使用域名跳轉
• 302 Found // 臨時重定向,未登陸的用戶訪問用戶中心重定向到登錄頁面
• 400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解
• 401 Unauthorized //請求未經(jīng)授權，這個狀態(tài)代碼必須和WWW-Authenticate報頭域一起使用
• 403 Forbidden //服務器收到請求，但是拒絕提供服務
• 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
• 500 Internal Server Error //服務器發(fā)生不可預期的錯誤
• 503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間后可能恢復正常

http的方法

• get:客戶端向服務端發(fā)起請求，獲得資源。請求獲得URL處所在的資源。
• post:向服務端提交新的請求字段。請求URL的資源后添加新的數(shù)據(jù)。
• head:請求獲取URL資源的響應報告，即獲得URL資源的頭部
• patch：請求局部修改URL所在資源的數(shù)據(jù)項
• put：請求修改URL所在資源的數(shù)據(jù)元素。
• delete：請求刪除url資源的數(shù)據(jù)

URI和URL的區(qū)別

URI，是uniform resource identifier，統(tǒng)一資源標識符，用來唯一的標識一個資源。Web上可用的每種資源如HTML文檔、圖像、視頻片段、程序等都是一個來URI來定位的

URI一般由三部組成：

1. 訪問資源的命名機制
2. 存放資源的主機名
3. 資源自身的名稱，由路徑表示，著重強調(diào)于資源。

URL是uniform resource locator，統(tǒng)一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明了如何locate這個資源。URL是Internet上用來描述信息資源的字符串，主要用在各種WWW客戶程序和服務器程序上，特別是著名的Mosaic。采用URL可以用一種統(tǒng)一的格式來描述各種信息資源，包括文件、服務器的地址和目錄等。

URL一般由三部組成：

1. 協(xié)議(或稱為服務方式)
2. 存有該資源的主機IP地址(有時也包括端口號)
3. 主機資源的具體地址。如目錄和文件名等

HTTPS和HTTP的區(qū)別

1. https協(xié)議需要到CA申請證書，一般免費證書很少，需要交費。
2. http是超文本傳輸協(xié)議，信息是明文傳輸；https 則是具有安全性的ssl加密傳輸協(xié) 議。
3. http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4. http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比http協(xié)議安全。
5. http默認使用80端口，https默認使用443端口

https是如何保證數(shù)據(jù)傳輸?shù)陌踩?/strong>