GET 和 POST 的區(qū)別

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

GET 請(qǐng)求可被緩存

GET 請(qǐng)求保留在瀏覽器歷史記錄中

GET 請(qǐng)求可被收藏為書簽

GET 請(qǐng)求不應(yīng)在處理敏感數(shù)據(jù)時(shí)使用

GET 請(qǐng)求有長(zhǎng)度限制

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

POST 請(qǐng)求不會(huì)被緩存

POST 請(qǐng)求不會(huì)保留在瀏覽器歷史記錄中

POST 不能被收藏為書簽

POST 請(qǐng)求對(duì)數(shù)據(jù)長(zhǎng)度沒有要求

dns使用的協(xié)議

既使用TCP又使用UDP

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

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

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

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

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

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

冪等

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

Cookies和session區(qū)別

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

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

應(yīng)用程序?qū)懭霐?shù)據(jù)的字節(jié)大小大于套接字發(fā)送緩沖區(qū)的大小

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

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

TCP粘包和拆包的解決策略

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

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

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

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

三次握手

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

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

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

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

四次揮手

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

服務(wù)端收到FIN，發(fā)送ACK，進(jìn)入CLOSE_WAIT狀態(tài)，客戶端收到這個(gè)ACK，進(jìn)入FIN_WAIT2狀態(tài)

服務(wù)端發(fā)送FIN，進(jìn)入LAST_ACK狀態(tài)

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

TIME_WAIT的狀態(tài)就是主動(dòng)斷開的一方（這里是客戶端），發(fā)送完最后一次ACK之后進(jìn)入的狀態(tài)。并且持續(xù)時(shí)間還挺長(zhǎng)的?？蛻舳薚IME_WAIT持續(xù)2倍MSL時(shí)長(zhǎng)，在linux體系中大概是60s，轉(zhuǎn)換成CLOSE狀態(tài)

TIME_WAIT

TIME_WAIT 是主動(dòng)關(guān)閉鏈接時(shí)形成的，等待2MSL時(shí)間，約4分鐘。主要是防止最后一個(gè)ACK丟失。 由于TIME_WAIT 的時(shí)間會(huì)非常長(zhǎng)，因此server端應(yīng)盡量減少主動(dòng)關(guān)閉連接

CLOSE_WAIT

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

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

假設(shè)最終的ACK丟失，server將重發(fā)FIN，client必須維護(hù)TCP狀態(tài)信息以便可以重發(fā)最終的ACK，否則會(huì)發(fā)送RST，結(jié)果server認(rèn)為發(fā)生錯(cuò)誤。TCP實(shí)現(xiàn)必須可靠地終止連接的兩個(gè)方向(全雙工關(guān)閉)，client必須進(jìn)入 TIME_WAIT 狀態(tài)，因?yàn)閏lient可能面 臨重發(fā)最終ACK的情形。

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

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

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

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

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

2.服務(wù)器保持了大量CLOSE_WAIT狀態(tài)，簡(jiǎn)單來(lái)說CLOSE_WAIT數(shù)目過大是由于被動(dòng)關(guān)閉連接處理不當(dāng)導(dǎo)致的。

一次完整的HTTP請(qǐng)求過程

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

講一下長(zhǎng)連接

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

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

http1.0請(qǐng)求與服務(wù)端的交互過程:

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

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

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

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

TCP如何保證可靠傳輸？

三次握手。

將數(shù)據(jù)截?cái)酁楹侠淼拈L(zhǎng)度。應(yīng)用數(shù)據(jù)被分割成 TCP 認(rèn)為最適合發(fā)送的數(shù)據(jù)塊（按字節(jié)編號(hào)，合理分片）

超時(shí)重發(fā)。當(dāng) TCP 發(fā)出一個(gè)段后，它啟動(dòng)一個(gè)定時(shí)器，如果不能及時(shí)收到一個(gè)確認(rèn)就重發(fā)

對(duì)于收到的請(qǐng)求，給出確認(rèn)響應(yīng)

校驗(yàn)出包有錯(cuò)，丟棄報(bào)文段，不給出響應(yīng)

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

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

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

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

詳細(xì)介紹http

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

特點(diǎn)

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

請(qǐng)求消息Request

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

響應(yīng)消息Response

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

狀態(tài)碼

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

http的方法

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

URI和URL的區(qū)別

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

URI一般由三部組成：

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

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

URL一般由三部組成：

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

HTTPS和HTTP的區(qū)別

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

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