POST跟GET的區(qū)別

作用

• GET用于獲取資源，而POST用于傳輸實(shí)體

參數(shù)

• GET的參數(shù)以字符串的格式出現(xiàn)在URL中，而POST的參數(shù)存儲(chǔ)在請(qǐng)求實(shí)體中。
• 因?yàn)閁RL只支持ASCII碼，故GET的參數(shù)如果存在中文等字符就需要先進(jìn)行編碼，POST參考支持標(biāo)準(zhǔn)字符集。

安全

• 安全的 HTTP 方法不會(huì)改變服務(wù)器狀態(tài)，也就是說(shuō)它只是可讀的。
• GET 方法是安全的，而 POST 卻不是，因?yàn)?POST 的目的是傳送實(shí)體主體內(nèi)容，這個(gè)內(nèi)容可能是用戶上傳的表單數(shù)據(jù)，上傳成功之后，服務(wù)器可能把這個(gè)數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)中，因此狀態(tài)也就發(fā)生了改變。
• 安全的方法除了 GET 之外還有：HEAD、OPTIONS。不安全的方法除了 POST 之外還有 PUT、DELETE。

緩存

• 請(qǐng)求報(bào)文的HTTP請(qǐng)求是可緩存的，包括GET和HEAD，但是PUT和DELETE不可緩存，POST在多數(shù)情況下不可緩存。

冪等性

• 冪等指同樣的請(qǐng)求被執(zhí)行一次與連續(xù)執(zhí)行多次的效果是一樣的，服務(wù)器的狀態(tài)也是一樣的。
• 所有的安全方法都是冪等的，在正確實(shí)現(xiàn)條件下，GET、POST、HEAD、PUT和DELETE方法都是冪等的，而POST不是。
• 引入冪等主要是為了處理同一個(gè)請(qǐng)求多次重復(fù)發(fā)送的情況，比如在請(qǐng)求相應(yīng)前失去連接，如果方法時(shí)冪等的，就可以放心的重發(fā)一次請(qǐng)求。這也是瀏覽器遇到POST會(huì)給用戶提示的原因：POST語(yǔ)義不是冪等的，重復(fù)請(qǐng)求可能會(huì)帶來(lái)意想不到的結(jié)果。
• 比如在微博這個(gè)場(chǎng)景里，GET的語(yǔ)義會(huì)被用在[看看我的timeline上最新的20條微博]這樣的場(chǎng)景，而POST的語(yǔ)義會(huì)被用在[發(fā)微博、點(diǎn)贊、評(píng)論]這樣的場(chǎng)景。

本部分參考：
HTTP
get和post的區(qū)別

TCP三次握手以及四次揮手

三次握手

A為客戶端、B為服務(wù)器端：

• 首先B處理監(jiān)聽（Listen）狀態(tài)，等待客戶端的請(qǐng)求。
• A向B發(fā)送連接請(qǐng)求報(bào)文，SYN=1,ACK=0，選擇一個(gè)初時(shí)的序號(hào)x。
• B收到連接請(qǐng)求報(bào)文之后，如果同意建立連接，則向A發(fā)送連接確認(rèn)報(bào)文，SYN=1,ACK=1，選擇初始序號(hào)為y，確認(rèn)序號(hào)為x+1。
• A收到B連接確認(rèn)報(bào)文之后，還要想B發(fā)出確認(rèn)，確認(rèn)號(hào)為y+1,序號(hào)為x+1。
• B收到A的確認(rèn)之后，連接建立。

四次揮手

A為客戶端、B為服務(wù)器端：

• A發(fā)送連接釋放報(bào)文，FIN=1，同時(shí)選擇序號(hào)為u。
• B收到之后發(fā)出確認(rèn)，ACK=1，確認(rèn)序號(hào)為u+1，同時(shí)選擇序號(hào)v。此時(shí)TCP為半關(guān)閉狀態(tài)，B可以向A發(fā)送數(shù)據(jù)，A不可以向B發(fā)送數(shù)據(jù)。
• 當(dāng)B不再需要連接之后，想A發(fā)送釋放報(bào)文，FIN=1，ACK=1,確認(rèn)序號(hào)為u+1，同時(shí)序號(hào)為w。
• A收到后發(fā)出確認(rèn)，ACK=1，確認(rèn)序號(hào)為w+1，序號(hào)為u+1，進(jìn)入TIME_WAIT狀態(tài)，等待2MSL（最大報(bào)文存活時(shí)間）后釋放連接。
• B收到A確認(rèn)之后釋放連接。

三次握手的原因

第三次握手時(shí)為了防止失效的連接請(qǐng)求到達(dá)服務(wù)器，讓服務(wù)器錯(cuò)開的打開鏈接。

客戶端發(fā)送的連接請(qǐng)求如果在網(wǎng)絡(luò)中滯留，那么就會(huì)隔很長(zhǎng)一段時(shí)間才能收到服務(wù)端返回的連接確認(rèn)。客戶端在等待一個(gè)超時(shí)重傳時(shí)間之后，就會(huì)重新發(fā)送請(qǐng)求連接，那么這個(gè)滯留的請(qǐng)求最后還是會(huì)到達(dá)服務(wù)器，如果不進(jìn)行三次握手，那么服務(wù)器就會(huì)打開兩個(gè)鏈接。

四次揮手的原因

客戶端發(fā)送釋放連接報(bào)文之后，服務(wù)器收到這個(gè)報(bào)文，就進(jìn)入了CLOSE_WAIT狀態(tài)，這個(gè)狀態(tài)時(shí)為了讓服務(wù)器發(fā)送還未傳送完成的數(shù)據(jù)，傳送完畢之后，服務(wù)器會(huì)發(fā)送釋放報(bào)文。

TIME_WATI

客戶端接收到服務(wù)器端的FIN報(bào)文之后進(jìn)入此狀態(tài)，此時(shí)并不是直接進(jìn)入CLOSED狀態(tài)，還需要等待一個(gè)時(shí)間計(jì)算器設(shè)置的時(shí)間2MSL。這么做有兩個(gè)原因：

• 確保最后一個(gè)確認(rèn)報(bào)文能夠到達(dá)，如果服務(wù)器沒有收到客戶端發(fā)送的確認(rèn)報(bào)文，那么就會(huì)重新發(fā)送連接釋放請(qǐng)求報(bào)文，客戶端等待一段時(shí)間就是為了處理這種情況的發(fā)生。
• 等待一段時(shí)間是為了讓本連接連續(xù)時(shí)間內(nèi)所有的報(bào)文都從網(wǎng)絡(luò)中消失，使得下一個(gè)新的連接不會(huì)出現(xiàn)舊的連接請(qǐng)求報(bào)文。

TCP和UDP的區(qū)別

用戶數(shù)據(jù)報(bào)協(xié)議UDP(User Datagram Protocal)：無(wú)連接，盡最大可能交付，沒有擁塞控制，面向報(bào)文（對(duì)于應(yīng)用層傳下來(lái)的報(bào)文不合并也不拆分，只是天界UDP首部），支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的交互通信。

傳輸控制協(xié)議TCP(Transmission Control Protocal):面向連接，提供可靠交互，有流量控制，擁塞控制，面向字節(jié)流（把應(yīng)用層傳下來(lái)的報(bào)文看成字節(jié)流，把字節(jié)流組織成大小不等的數(shù)據(jù)塊），每一條TCP連接只能是對(duì)對(duì)點(diǎn)的（一對(duì)一）。

HTTP

長(zhǎng)連接和短連接

在HTPP/1.0中默認(rèn)使用短連接，也就是客戶端每次與服務(wù)端進(jìn)行一次HTTP操作，都要建立一次連接，任務(wù)結(jié)束就斷開連接。

而從HTTP/1.1起，默認(rèn)使用長(zhǎng)連接，用以保持連接特性。使用長(zhǎng)連接的HTTP協(xié)議，會(huì)在響應(yīng)頭加入：Connection:keep-alive
在使用長(zhǎng)連接的情況下，當(dāng)一個(gè)網(wǎng)頁(yè)打開完成之后，客戶端與服務(wù)端之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，客戶端再次訪問這個(gè)服務(wù)器時(shí)，會(huì)繼續(xù)使用一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接，它有一個(gè)保持時(shí)間。

HTTP協(xié)議的長(zhǎng)連接和短連接，實(shí)質(zhì)上是TCP協(xié)議的長(zhǎng)連接和短連接。

HTTP跟HTTPS

HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文，因此使用HTTP協(xié)議傳輸隱私信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是就設(shè)計(jì)出SSL(Secure Sockets Layer)協(xié)議用于對(duì)HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密，從而誕生了HTTPS。

區(qū)別

• HTTPS協(xié)議需要CA申請(qǐng)證書。
• HTTP是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS則是具有安全性的SSL加密傳輸協(xié)議。
• HTTP的端口是80，而HTTPS的端口是443。
• HTTP是無(wú)狀態(tài)的，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

TCP可靠傳輸

TCP使用超時(shí)重傳來(lái)實(shí)現(xiàn)可靠傳輸，如果一個(gè)已經(jīng)發(fā)送的報(bào)文段在超時(shí)時(shí)間內(nèi)沒有收到確認(rèn)，那么就重傳這個(gè)報(bào)文段。

TCP的窗口滑動(dòng)

窗口是緩存的一部分，用來(lái)暫時(shí)存放字節(jié)流。發(fā)送方和接收方各有一個(gè)窗口，接收方通過(guò)TCP報(bào)文段中窗口字段告訴發(fā)送方自己的窗口大小，發(fā)送方根據(jù)這個(gè)值和其他信息設(shè)置自己的窗口大小。

發(fā)送窗口內(nèi)的字節(jié)都允許被發(fā)送，接收窗口的字節(jié)都允許被接收，如果發(fā)送窗口昨部的字節(jié)已經(jīng)發(fā)送并且受到確認(rèn)，那么就講發(fā)送窗口向右滑動(dòng)一定距離，直到左部第一個(gè)字節(jié)不是已發(fā)送并且已確定的狀態(tài)。接受窗口類似，接收窗口左部字節(jié)已經(jīng)發(fā)送確認(rèn)并交付主機(jī)，講向右滑動(dòng)窗口。

接收窗口只會(huì)對(duì)窗口內(nèi)最后一個(gè)按序到達(dá)的字節(jié)進(jìn)行確認(rèn)，例如接收窗口已經(jīng)收到的字節(jié){31,34,35}，其中{31}按序到達(dá)，而{34,35}不是，因此只會(huì)對(duì)字節(jié)31進(jìn)行確認(rèn)。發(fā)送方得到一個(gè)字節(jié)的確認(rèn)之后，就知道這個(gè)字節(jié)之前的所有字節(jié)都已經(jīng)被接收。

TCP流量控制

流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來(lái)得及接收。

接收方發(fā)送的確認(rèn)報(bào)文中的窗口字段可以用來(lái)控制發(fā)送窗口大小，從而影響發(fā)送方的發(fā)送速率。講窗口字段設(shè)置為0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

TCP擁塞控制

如果網(wǎng)絡(luò)出現(xiàn)擁塞，分組將會(huì)丟失，此時(shí)發(fā)送方會(huì)繼續(xù)重傳，從而導(dǎo)致網(wǎng)絡(luò)擁塞程度更高。因此當(dāng)網(wǎng)絡(luò)出現(xiàn)擁塞時(shí)，應(yīng)當(dāng)控制發(fā)送方的速率。這一點(diǎn)跟流量控制很像，但是出發(fā)點(diǎn)不同。流量控制是為了讓接收方能來(lái)得及接收，而擁塞控制是為了降低整個(gè)網(wǎng)絡(luò)的擁塞程度。

TCP主要通過(guò)四種算法來(lái)進(jìn)行擁塞控制：慢開始、擁塞避免、快回復(fù)、快重傳。

發(fā)送方需要維護(hù)一個(gè)擁塞窗口(cwnd)的狀態(tài)變量，注意擁塞窗口跟發(fā)送方窗口的區(qū)別，擁塞窗口只是一個(gè)狀態(tài)變量，實(shí)際決定發(fā)送方能發(fā)送多少數(shù)據(jù)是發(fā)送方窗口。

為了方便討論，做如下假設(shè)：

• 接收方有足夠大的接收緩存，因此不會(huì)發(fā)送流量控制。
• 雖然TCP的窗口基于字節(jié)，但是這里設(shè)窗口的大小單位為報(bào)文段。

慢開始與擁塞避免

發(fā)送最初執(zhí)行慢開始，令cwnd=1，發(fā)送方只能發(fā)送1個(gè)報(bào)文段，當(dāng)收到確認(rèn)后，令cwnd加倍，因此之后發(fā)送方能夠發(fā)送的報(bào)文段數(shù)量為：2、4、8...

注意到?jīng)]開始每個(gè)輪次都講cwnd加倍，這樣會(huì)讓cwnd增長(zhǎng)速度非常快，從而發(fā)送方的發(fā)送速率增長(zhǎng)過(guò)快，網(wǎng)絡(luò)擁塞的可能就越高。設(shè)置一個(gè)慢開始門限ssthresh，當(dāng)cwnd >= ssthresh時(shí)，進(jìn)入擁塞避免，每個(gè)輪次只將cwnd加1。

如果出現(xiàn)了超時(shí)，則令ssthresh = cwnd / 2，然后重新執(zhí)行慢開始。

快恢復(fù)和快重傳

在接收方，要求每次接收到報(bào)文段都應(yīng)該對(duì)最后一個(gè)已收到的有序報(bào)文段進(jìn)行確認(rèn)，例如接收到M1和M2，此時(shí)收到M4，應(yīng)當(dāng)發(fā)送M2的確認(rèn)。

在發(fā)送方，如果收到三個(gè)重復(fù)確認(rèn)，那么就可以知道下一個(gè)報(bào)文段丟失，此時(shí)執(zhí)行快重傳，立即重傳下一個(gè)報(bào)文段。例如收到三個(gè)M2，則M3丟失，立即重傳M3。

在這種情況下，只是丟失個(gè)別報(bào)文段，而不是網(wǎng)絡(luò)擁塞。因此執(zhí)行快恢復(fù)，令ssthresh = cwnd / 2，cwnd = ssthresh，注意此時(shí)直接進(jìn)入擁塞避免。

慢開始和快恢復(fù)的快慢指的是cwnd的設(shè)定值，而不是cwnd的增長(zhǎng)速率。慢開始cwnd設(shè)定為1，而快恢復(fù)cwnd設(shè)定為ssthresh。

TCP拆包跟粘包

TCP是個(gè)面向字節(jié)流協(xié)議，就是沒有界限的一串?dāng)?shù)據(jù)，大家可以想想河里的流水，是連成一片的，其間并沒有分界線。TCP底層并不了解上層業(yè)務(wù)數(shù)據(jù)的具體含義，它會(huì)根據(jù)TCP緩存區(qū)的實(shí)際情況進(jìn)行包的劃分。所以業(yè)務(wù)上認(rèn)為，一個(gè)完整的包可能會(huì)被TCP拆分為多個(gè)包進(jìn)行發(fā)送也有可能多個(gè)小的包封裝成一個(gè)大的數(shù)據(jù)包發(fā)送，這就是所謂的TCP粘包和拆包問題。

產(chǎn)生原因:

• 應(yīng)用程序write寫入的字節(jié)大小大于套接字發(fā)送緩存區(qū)的大小。
• 進(jìn)行MSS大小的TCP分段。
• 以太網(wǎng)的payload大于MTU進(jìn)行IP分片。

解決策略：
由于底層的TCP無(wú)法理解上層的業(yè)務(wù)數(shù)據(jù)，所以在底層是無(wú)法保證用戶數(shù)據(jù)包不被拆分和重組的，這個(gè)問題只能通過(guò)上層的應(yīng)用協(xié)議棧設(shè)計(jì)來(lái)解決，根據(jù)業(yè)界的主流協(xié)議的解決方案，可以歸納如下：

• 消息定長(zhǎng)，規(guī)定每個(gè)報(bào)文的大小固定為200字節(jié)，如果不夠，空位補(bǔ)空格。
• 在包尾添加換行符進(jìn)行分割，例如FTP協(xié)議。
• 將消息分為消息頭和消息體，消息頭包含表示消息總長(zhǎng)度（或消息體長(zhǎng)度）的字段，通常設(shè)計(jì)思路為消息頭的第一個(gè)字段使用int32來(lái)表示消息的總長(zhǎng)度。
• 更復(fù)雜的應(yīng)用層協(xié)議。

Cookie跟Session

• HTTP是一種無(wú)狀態(tài)的協(xié)議，無(wú)法分辨連接是誰(shuí)發(fā)起的，Cookie跟Session就是為了解決這個(gè)問題的機(jī)制。

Cookie

Cookie 是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會(huì)在瀏覽器之后向同一服務(wù)器再次發(fā)起請(qǐng)求時(shí)被攜帶上，用于告知服務(wù)端兩個(gè)請(qǐng)求是否來(lái)自同一瀏覽器。由于之后每次請(qǐng)求都會(huì)需要攜帶 Cookie 數(shù)據(jù)，因此會(huì)帶來(lái)額外的性能開銷（尤其是在移動(dòng)環(huán)境下）。

Cookie 曾一度用于客戶端數(shù)據(jù)的存儲(chǔ)，因?yàn)楫?dāng)時(shí)并沒有其它合適的存儲(chǔ)辦法而作為唯一的存儲(chǔ)手段，但現(xiàn)在隨著現(xiàn)代瀏覽器開始支持各種各樣的存儲(chǔ)方式，Cookie 漸漸被淘汰。新的瀏覽器 API 已經(jīng)允許開發(fā)者直接將數(shù)據(jù)存儲(chǔ)到本地，如使用 Web storage API （本地存儲(chǔ)和會(huì)話存儲(chǔ)）或 IndexedDB。

Session

存在服務(wù)器的一種用來(lái)存放用戶數(shù)據(jù)的類HashTable結(jié)構(gòu)。
瀏覽器第一次發(fā)送請(qǐng)求時(shí)，服務(wù)器自動(dòng)生成了一HashTable和一Session ID來(lái)唯一標(biāo)識(shí)這個(gè)HashTable，并將其通過(guò)響應(yīng)發(fā)送到瀏覽器。瀏覽器第二次發(fā)送請(qǐng)求會(huì)將前一次服務(wù)器響應(yīng)中的Session ID放在請(qǐng)求中一并發(fā)送到服務(wù)器上，服務(wù)器從請(qǐng)求中提取出Session ID，并和保存的所有Session ID進(jìn)行對(duì)比，找到這個(gè)用戶對(duì)應(yīng)的HashTable。
一般這個(gè)值會(huì)有個(gè)時(shí)間限制，超時(shí)后毀掉這個(gè)值，默認(rèn)30分鐘。

區(qū)別

• Cookie數(shù)據(jù)存放在瀏覽器，session數(shù)據(jù)存放在服務(wù)器上。
• Cookie數(shù)據(jù)不是很安全，別人可以分析放在本地Cookie進(jìn)行Cookie欺騙。
• Session會(huì)在一定時(shí)間保存在服務(wù)器，當(dāng)訪問增多時(shí)，會(huì)占有服務(wù)器性能。

跨域

跨域指發(fā)起請(qǐng)求的域與該請(qǐng)求指向的資源所在的域不一樣。
同域指：協(xié)議+域名+端口號(hào)均相同。

通常瀏覽器會(huì)對(duì)跨域做出限制，瀏覽器之所以要對(duì)跨域請(qǐng)求做出限制，是處于安全方法的考慮，因?yàn)榭缬蛘?qǐng)求可能被不法分子利用來(lái)發(fā)動(dòng)CSRF攻擊。

跨域的解決方式

JSONP

• JSONP是一種非官方的跨域數(shù)據(jù)交互協(xié)議，其本質(zhì)上是利用<script><img><iframe>等標(biāo)簽不受同源策略限制，可以從不用域加載并執(zhí)行資源的特性，來(lái)實(shí)現(xiàn)數(shù)據(jù)跨域傳輸。
• JSONP有兩部分組成，回調(diào)函數(shù)和數(shù)據(jù)，回調(diào)函數(shù)是當(dāng)響應(yīng)到來(lái)時(shí)應(yīng)該在頁(yè)面中調(diào)用的函數(shù)，而數(shù)據(jù)就是傳入回調(diào)函數(shù)中的JSON數(shù)據(jù)。
• JSONP的理念是，與服務(wù)端Javascript代碼中調(diào)用了約定好的回調(diào)函數(shù)，并且將數(shù)據(jù)作為參數(shù)進(jìn)行傳遞。當(dāng)網(wǎng)頁(yè)接收到這段javascript代碼后，就會(huì)執(zhí)行這個(gè)回調(diào)函數(shù)，這時(shí)數(shù)據(jù)已經(jīng)成功傳輸?shù)娇蛻舳肆恕?/li>

CORS

跨域資源共享Cross-Origin Resource sharing是一種新的W3C的標(biāo)準(zhǔn)，它新增的一組HTTP首部字段，運(yùn)行服務(wù)端起聲明哪些源站有權(quán)限訪問哪些資源。

HTTP協(xié)議Header解析

CORS 中新增的 HTTP 首部字段：

• Access-Control-Allow-Origin：響應(yīng)首部中可以攜帶這個(gè)頭部表示服務(wù)器允許哪些域可以訪問該資源。
• Access-Control-Allow-Methods：該首部字段用戶預(yù)測(cè)請(qǐng)求的響應(yīng)，指明實(shí)際請(qǐng)求所允許使用的HTTP方法。
• Access-Control-Allow-Header：允許攜帶的首部字段。
• Access-Control-Max-Age：請(qǐng)求能被緩存多久。
• Access-Control-Allow-Credentials：可選，是否允許發(fā)送cookie。
• Origin：請(qǐng)求源站，不管是否跨域，Origin字段總是被發(fā)送。
• Access-Control-Request-Method：實(shí)際請(qǐng)求的方法。
• Access-Control-Request-Header：實(shí)際請(qǐng)求所攜帶的首部。

參考

HTTP長(zhǎng)連接、短連接究竟是什么
HTTP與HTTPS的區(qū)別
什么是跨域請(qǐng)求以及實(shí)現(xiàn)跨域的方案

總結(jié)

以上是生活随笔為你收集整理的centos网络隔一段时间就断_计算机网络总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。