Http報(bào)文

HTTP請求報(bào)文由請求行、請求頭部、空行和請求包體4個部分組成，如下圖所示：

1.1、通用報(bào)文

General: //通用報(bào)文
Request Method: GET
Status Code: 200 OK
Remote Address: 47.111.45.248:80
Referrer Policy: origin

1.2、請求報(bào)文

Request Headers: //客戶端請求頭
Accept : image/webp,image/apng,image/*,*/*;q=0. //瀏覽器客戶端告訴告訴服務(wù)端能接受什么樣類型的數(shù)據(jù)
Accept-Encoding: gzip, deflate //瀏覽器客戶端告訴服務(wù)器能接受什么編碼格式，包括字符編碼，壓縮方式
Accept-Language: zh-CN,zh;q=0.9 //客戶端告訴瀏覽器接受什么樣的語言
Accept-Ranges: bytes //斷點(diǎn)續(xù)傳
ETag: "23411b8a827d31:0”. //304
Cache-Control : no-cache
Connection : keep-alive //客戶端告訴服務(wù)端的連接方式：長連接
X-UA-Compatible: IE=10
X-Frame-Options: SAMEORIGIN
Cookie: _ga=GA1.2.1796862747.1547952793; __gads=ID=60d16307ea494dae:T=1547952794:S=ALNI_MYsoIBtEfg7-PJNMTds68JgtxnQrw; UM_distinctid=168832d7c157de-0ad85a26ff65a-35617601-13c680-168832d7c168b3;
Host: www.cnblogs.com。 //要請求的主機(jī)及端口目的地
Pragma: no-cache
Referer: http://www.cnblogs.com/ //客戶端告訴瀏覽器這個請求是從哪里過來的，請求來源
User-Agent: Mozilla/5.0 (macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (Khtml, like Gecko) Chrome/73.0.3683.86 Safari/537.36。 //瀏覽器指定，告訴服務(wù)器，使用的瀏覽器的版本和名稱自動發(fā)送

1.3、響應(yīng)報(bào)文

Response Headers: //服務(wù)器返回http頭
HTTP/1.1 200 OK
Date: Tue, 16 Apr 2019 05:13:48 GMT //什么時候響應(yīng)會瀏覽器
Content-Type : image/x-icon。 //響應(yīng)的內(nèi)容是什么類型，采用的是什么編碼，對應(yīng)請求的accept設(shè)置內(nèi)容
Content-Length : 1332 //服務(wù)端告訴瀏覽器相應(yīng)實(shí)體的大小
Connection: keep-alive ／close //服務(wù)端告訴瀏覽器連接的方式為長連接，管道連接，異步響應(yīng)http的請求，http1.1，提高效率；
Cache-Control : max-age=120. //服務(wù)端告訴瀏覽器緩存的時間最長為120s
Last-Modified : Fri, 28 Jul 2017 09:18:56 GMT //服務(wù)器文本最后一次修改的時間. 304

ps：在實(shí)際情況中使用： response.setContentType("text/html;charset=UTF-8”); 來設(shè)置編碼以解決中文的亂碼問題。

（0）、Connection: keep-alive ／close 服務(wù)端告訴瀏覽器連接的方式為長連接，管道連接，異步響應(yīng)http的請求，http1.1，提高效率；

（1）、MIME Type:是描述消息內(nèi)容類型的因特網(wǎng)標(biāo)準(zhǔn)，常見的數(shù)據(jù)幾種類型

文本文件:text/html,text/plain,text/css,application/xhtml+xml,application/xml
圖片文件:image/jpeg,image/gif,image/png.
視頻文件:video/mpeg,video/quicktime

我們可以通過兩種方式來設(shè)置文件的渲染類型，

第一種是 Accept-客戶端
第二種是 Content-Type-服務(wù)器

Accept : 表示客戶端希望接受的數(shù)據(jù)類型，即告訴服務(wù)器我需要什么媒體類型的數(shù)據(jù)，此時服務(wù)器應(yīng)該根據(jù) Accept 請求頭生產(chǎn)指定媒體類型的數(shù)據(jù)。

Content-Type : 表示發(fā)送端發(fā)送的實(shí)體數(shù)據(jù)類型，比如我們應(yīng)該寫過類似的: resposne.setContentType(“application/json;charset=utf-8”)的代碼，表示服務(wù)端返回的數(shù)據(jù) 格式是 json。

如果 Accept 和 Content-Type 不一致，假如說 Accept 要接收的類型是 image/gif，但是服務(wù) 端返回的數(shù)據(jù)是 text/html，那么瀏覽器將會無法解析。

（2） .Cache-Control 作用：

客戶端瀏覽器用來判斷是否需要用本地緩存。默認(rèn)值為private；常用值有private、no-cache、max-age、must-revalidate。

具體場景舉例：

a.打開新窗口時值為 private、no-cache、must-revalidate ，那么打開新窗口訪問時都會重新訪問服務(wù)器。而如果指定了 max-age 和 expire 值（單位為秒），那么在此值內(nèi)的時間里就不會重新訪問服務(wù)器：

例如：Cache-control: max-age=5(表示當(dāng)訪問此網(wǎng)頁后的5秒內(nèi)再次訪問不會去服務(wù)器)

b.在地址欄回車.值為 private或must-revalidate則只有第一次訪問時會訪問服務(wù)器，以后就不再訪問。

值為 no-cache，那么每次都會訪問。

值為 max-age 和 expire，則在過期之前不會重復(fù)訪問。

c.按后退按扭

值為private、must-revalidate、max-age，則不會重訪問，

值為no-cache，則每次都重復(fù)訪問

d.按刷新按鈕

無論為何值，都會重復(fù)訪問；

（3）、Cookie 作用：客戶端瀏覽器用來存儲一些用戶信息以便讓服務(wù)器辨別用戶身份的（大多數(shù)需要登錄的網(wǎng)站上面會比較常見），比如用戶名和密碼，sessionId等。

（4）、If-Modify-Since 作用：

把瀏覽器端緩存頁面的最后修改時間（精確到秒）發(fā)送到服務(wù)器去，服務(wù)器會把這個時間與服務(wù)器上實(shí)際文件的最后修改時間進(jìn)行對比。如果時間一致，那么返回304，客戶端就直接使用本地緩存文件。如果時間不一致，就會返回200和新的文件內(nèi)容以及新的修改時間(Last-Modify)。客戶端接到之后，會丟棄舊文件，把新文件緩存起來，并顯示在瀏覽器中。

（5）、Etag的使用場景：

1.有些文件需要頻繁更新，但是文件內(nèi)容并沒有變化。

聰明的開發(fā)者會把 Last-Modified和ETags請求的http報(bào)頭一起使用，提高瀏覽器性能。這樣可利用客戶端（例如瀏覽器）的緩存。因?yàn)榉?wù)器首先產(chǎn)生Last-Modified/Etag標(biāo)記，服務(wù)器可在稍后使用它來判斷頁面是否已經(jīng)被修改。本質(zhì)上，客戶端通過將該記號傳回服務(wù)器要求服務(wù)器驗(yàn)證其（客戶端）緩存。

過程如下:

1.客戶端請求一個頁面（A）。
2.服務(wù)器返回頁面A，并在給A加上一個Last-Modified/ETag。
3.客戶端展現(xiàn)該頁面，并將頁面連同Last-Modified/ETag一起緩存。
4.客戶再次請求頁面A，并將上次請求時服務(wù)器返回的Last-Modified/ETag一起傳遞給服務(wù)器。
5.服務(wù)器檢查該Last-Modified或ETag，并判斷出該頁面自上次客戶端請求之后還未被修改，直接返回響應(yīng)304和一個空的響應(yīng)體。

（6）、如果服務(wù)器又設(shè)置了Cache-Control:max-age和Expires呢，怎么辦？

答案是同時使用，也就是說在完全匹配If-Modified-Since和If-None-Match即檢查完修改時間和Etag之后，服務(wù)器才能返回304.(不要陷入到底使用誰的問題怪圈)

（7）、如果傳輸?shù)奈募艽笤趺崔k？

方案一：通過壓縮文件： Accept-Encoding: gzip , deflate ;

方案二：分割傳輸，瀏覽器逐步顯示；

狀態(tài)碼

1XX ：接受的請求正在處理

200: 請求正常處理

3xx開頭，資源文件

301: 資源被永久刪除，永久重定向到新的網(wǎng)址

302: 舊的資源還在，只是暫時性的重定向資源

重定向原因：

（1）網(wǎng)站調(diào)整（如改變網(wǎng)頁目錄結(jié)構(gòu)）；

（2）網(wǎng)頁被移到一個新地址；

（3）網(wǎng)頁擴(kuò)展名改變(如應(yīng)用需要把.php改成.Html或.shtml)。

304: 返回上次請求資源未作改動,驗(yàn)證瀏覽器的緩存機(jī)制 Etag
307: 資源的重定向，但是不會把post改為get操作；
4xx開頭：客戶端
400: 請求參數(shù)錯誤
401: 客戶端無權(quán)訪問,要去輸入用戶名密碼之類的授權(quán)信息
403: 禁止訪問(讀寫權(quán)限等影響)
404: 請求的資源不存在
5xx開頭：服務(wù)端
500: 服務(wù)內(nèi)部錯誤
502: 網(wǎng)關(guān)錯誤
503: 臨時過載或者維護(hù),導(dǎo)致服務(wù)端無法正常處理請求

擁塞

計(jì)算機(jī)網(wǎng)絡(luò)中的帶寬，交換節(jié)點(diǎn)中的緩存和處理機(jī)制，都是網(wǎng)絡(luò)資源。在某段時間內(nèi)，若對網(wǎng)絡(luò)中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就會變壞。

這種情況就叫做擁塞。擁塞發(fā)生的主要原因是網(wǎng)絡(luò)能夠提供的資源不足以滿足用戶的需求，這些資源包括緩存空間、鏈路帶寬容量和中間節(jié)點(diǎn)的處理能力。

由于互聯(lián)網(wǎng)的設(shè)計(jì)機(jī)制（任何人任何時間都能共享網(wǎng)絡(luò)資源）導(dǎo)致其缺乏“接納控制”能力，因此在網(wǎng)絡(luò)資源不足時不能限制用戶數(shù)量，只能靠降低服務(wù)質(zhì)量來繼續(xù)為用戶服務(wù)，也就是“盡力而為”服務(wù)。但是也不是說增加網(wǎng)絡(luò)資源，就可以避免網(wǎng)絡(luò)擁塞。

擁塞雖然是由于網(wǎng)絡(luò)資源的缺乏引起的，但是單純增加資源并不能避免擁塞的發(fā)生。有時增加緩存空間到一定程度時，只會加重?fù)砣皇菧p輕擁塞，這是因?yàn)楫?dāng)數(shù)據(jù)包經(jīng)過長期時間排隊(duì)完成轉(zhuǎn)發(fā)時，他們可能早已經(jīng)超時，從而引起源端超時重發(fā)，而這些數(shù)據(jù)包還會繼續(xù)傳輸?shù)较乱粋€路由器，從而浪費(fèi)網(wǎng)絡(luò)資源，加重網(wǎng)絡(luò)擁塞。事實(shí)上，緩存空間不足導(dǎo)致的丟包更多的是擁塞的“癥狀”而非原因。

另外，增加鏈路寬帶及提高處理能力也不能解決擁塞問題。

例如我們有4臺ABCD主機(jī)和一個路由，所有的鏈路帶寬都是1Gbps，如果A和B 同時以1Gbps的速率發(fā)送數(shù)據(jù)，則路由器的輸入速率為2Gpbs，從而產(chǎn)生擁塞。避免擁塞的方法是控制AB的發(fā)送速率，例如AB都是0.5Gpbs，但是如果此時D也以1Gpbs的速率發(fā)送，那么擁塞還是無法避免，況且用戶主機(jī)不可能只有4個。所以說擁塞只是一個動態(tài)問題，我們沒有辦法用一個靜態(tài)方案去解決，從這個意義上說，擁塞是不可避免的！！

擁塞是一個全局控制的過程，他不像點(diǎn)對點(diǎn)的流控機(jī)制，是一個局部的控制！

TCP的擁塞控制算法

TCP的擁塞控制由4個核心的算法組成：慢啟動（slow start）、擁塞避免（Congestion voidance）、快速重傳（Fast Retransmit）和快速恢復(fù)（Fast Recovery）。

擁塞控制，在發(fā)送方維持著一個擁塞窗口cwmd（congestion window）的狀態(tài)量。擁塞窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動態(tài)的變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口，另外考慮到接收方的接收能力，發(fā)送窗口可能小于擁塞窗口。

4.1、慢啟動（slow start）

早期的開發(fā)的TCP應(yīng)用在啟動一個連接時會向網(wǎng)絡(luò)中發(fā)送大量的數(shù)據(jù)包，這樣很容易導(dǎo)致路由器緩存空間耗盡，網(wǎng)絡(luò)發(fā)生擁塞，使得TCP連接的吞吐量急劇下降。由于TCP源端一開始并不知道網(wǎng)絡(luò)資源當(dāng)前的利用狀況，因此新建立的TCP連接不能一開始就發(fā)送大量的數(shù)據(jù)，而只能逐步增加每次發(fā)送的數(shù)據(jù)量，以避免上述現(xiàn)象的發(fā)生。具體來說，當(dāng)新建立一個連接時，CWND初始化為1個最大報(bào)文段（MSS）大小，發(fā)送端開始按照擁塞窗口大小發(fā)送數(shù)據(jù)，每當(dāng)有一個報(bào)文被確認(rèn)，cwnd就增加1個MSS大小。這樣cwnd的值就隨著網(wǎng)絡(luò)往返時間（Round trip time，RTT）呈指數(shù)級增長，事實(shí)上，慢啟動的速度一點(diǎn)也不慢，只是他的起點(diǎn)比較低一點(diǎn)兒而已，指數(shù)級的增長率是十分快的。

該算法的思想主要是一種探測一下網(wǎng)路的擁塞程度，就是不要一開始就發(fā)送大量的數(shù)據(jù)，也就是說有小到大逐漸增加（指數(shù)）擁塞窗口的大小。

我們可以簡單計(jì)算：

開始cwnd=1
經(jīng)過1個RTT后， cwnd=2*1=2
經(jīng)過2個RTT后， cwnd=2*2=4
經(jīng)過3個RTT后， cwnd=2*4=8
如果寬帶為W，那么經(jīng)過RTT*log2W時間就可以占滿帶寬；

4.2、擁塞避免（Congestion voidance）

如果按上述的慢啟動的思想如果不加以控制的話，毫無疑問地發(fā)生網(wǎng)絡(luò)擁塞，當(dāng)cwnd很快增長上來的時候，也很快利用了網(wǎng)絡(luò)的資源，但是cwnd不能一直這樣增長，一定需要某個限制。TCP使用了一個慢啟動門限（ssthresh）的變量，當(dāng)cwnd超過該值后，慢啟動結(jié)束，進(jìn)入擁塞避免階段。對于大多數(shù)的TCP是吸納來說，ssthresh的值是65535（同樣以16bit來計(jì)算）。擁塞避免的思想就是轉(zhuǎn)指數(shù)增大變?yōu)榧臃ň€性增大。這樣就可以避免增長過快導(dǎo)致網(wǎng)絡(luò)擁塞，慢慢地增加調(diào)整到網(wǎng)絡(luò)的最佳值。

期具體ssthresh的用法如下：

當(dāng)cwnd<ssthresh時，使用慢開始算法。
當(dāng)cwnd>ssthresh時，改用擁塞避免算法。
當(dāng)cwnd=ssthresh時，慢開始與擁塞避免算法任意。

注意：如果當(dāng)前的cwnd達(dá)到慢啟動的閾值，則試探性的發(fā)送一個segment，如果服務(wù)器沒有響應(yīng)，TCP認(rèn)為網(wǎng)絡(luò)能力下降，必須降低慢啟動閾值，同時為了避免形式繼續(xù)惡化，有可能將窗口降低為1

4.3、快速重傳（Fast Retransmit）

正常情況下，按照上一節(jié)講的消息重傳是等到定時器超時（RTO）后在重傳，但有時候不需要等那么久也可以重傳。比如客戶端向服務(wù)器發(fā)送了5個段數(shù)據(jù)包。第三個丟失，其他正常，那么客戶端會收到3個包2的ACK，而4、5正常到達(dá)后會被服務(wù)器緩存起來但是不會發(fā)送相應(yīng)包的ACK，因?yàn)門CP是基于積累確認(rèn)機(jī)制，以確保丟失的包能被重發(fā)，數(shù)據(jù)接收準(zhǔn)確，ACK必須是連續(xù)的。這個時候就不必在等待RTO的超時時間了，服務(wù)器判斷已經(jīng)丟失了就可以馬上快速重傳，提高效率。

快速重傳算法規(guī)定，發(fā)送方只要一連收到三個重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對方尚未收到的報(bào)文文件，而不必繼續(xù)等待設(shè)置重傳計(jì)時器時間到期。

4.4、快速恢復(fù)（Fast Recovery）

其實(shí)快速恢復(fù)并不是單獨(dú)存在的，它是快速重傳的后續(xù)處理。通常認(rèn)為客戶端接收到3個ACK后，就會開始快速重傳，但是如果還有更多的重復(fù)ACK呢，這個時候就是快速恢復(fù)要做的。

a、當(dāng)發(fā)送方連續(xù)收到三個重復(fù)確認(rèn)時，就執(zhí)行“乘法減小”算法，把ssthresh門限減半（也即cwnd=ssthresh/2）.但是接下去并不執(zhí)行慢開始算法；

b、考慮到此時能連續(xù)收到3個ACK，說明網(wǎng)絡(luò)沒有擁塞，執(zhí)行加法原則，有幾個ACK就加幾個段的字節(jié)數(shù)，或者可以將cwnd=ssthresh，直接進(jìn)入擁塞避免算法。

四種算法相互間的合作運(yùn)行圖如下所示：

問題思考

問題一：如何檢測擁塞?

首先來看一下TCP是如何確定網(wǎng)絡(luò)進(jìn)入擁塞的，TCP認(rèn)為網(wǎng)絡(luò)擁塞的主要依據(jù)是它重傳了一個報(bào)文段。上面提到過，TCP對每一個報(bào)文段都有一個定時器，稱為重傳定時器（RTO），當(dāng)RTO超時且還沒有得到數(shù)據(jù)確認(rèn)，那么TCP就會對該報(bào)文段進(jìn)行重傳，當(dāng)發(fā)生超時時，那么出現(xiàn)擁塞的可能性就很大，某個報(bào)文段可能在網(wǎng)絡(luò)中某處丟失，并且后續(xù)的報(bào)文段也沒有了消息，在這種情況下，TCP反應(yīng)比較“強(qiáng)烈”：

（1）把ssthresh降低為cwnd值的一半；
（2）把cwnd重新設(shè)置為1；
（3）重新進(jìn)入慢啟動過程；

可以看出，從整體上講，TCP擁塞控制窗口變化的原則是： AIMD（Additive Increase Multiplicative Decrease）。TCP/IP模型中，屬于運(yùn)輸層，即：加性增，乘性減，或者叫做“和式增加，積式減少”。該原則很好地保證了流之間的公平性，因?yàn)橐坏┏霈F(xiàn)丟包，那么立即減半退避，可以給其他新建的流留有足夠的空間，從而保證整個的公平性。

問題二：為什么客戶端沒接收到一個ACK，會把cwnd增加一個segment呢?

這是基于管道模型的“數(shù)據(jù)包守恒”原則，及同一時刻在網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)包數(shù)量是恒定的，只有當(dāng)“舊”數(shù)據(jù)包離開網(wǎng)路后，才能發(fā)送“新”數(shù)據(jù)包進(jìn)入網(wǎng)絡(luò)。如果發(fā)送方收到一個ACK，則認(rèn)為有一個數(shù)據(jù)已經(jīng)離開了網(wǎng)絡(luò)，于是將擁塞窗口+1，如果網(wǎng)路能夠嚴(yán)格遵守該“數(shù)據(jù)包守恒”原則，則擁塞的法神會大大減少。

有趣的聯(lián)想： TCP擁塞的解決就像是我們生活中的交通堵車？

其中有兩個原則：

一、擁塞不可避免，單純增加資源并不能避免擁塞的發(fā)生；

二、數(shù)據(jù)包守恒原則。如果政府只是花資金修路，拓寬公路，并不能避免堵車，因?yàn)檐嚨臄?shù)量是不定的，旅游季可能有很多，也許一時間段沒有車，這時候只能從源頭控制。對車流量進(jìn)行控制：例如限制車輛進(jìn)入主公路，根據(jù)實(shí)際的情況，如果某一時間段車輛少，則可以慢慢增加車輛進(jìn)入該公路段，但是當(dāng)達(dá)到一個閾值，就要放緩車輛進(jìn)入的速度，并實(shí)時地探測整條路的狀況，如果情況緊急，則立刻將車流量減少一半，將車流量降到最低，然后在重新回到慢啟動轉(zhuǎn)態(tài)。使整條公路能夠保持暢通，達(dá)到最大的運(yùn)行效率。