前言

上一篇 HTTP 講到了第3章。這次我們講第4章。有太多要學(xué)，不是科班出生的表示壓力有點大，需要趕緊學(xué)，幸運的是我現(xiàn)在這家公司每個人我都能在他們身上學(xué)到東西。

TCP 是啥

HTTP的上一層，傳輸層用的是TCP ，書中簡單的說了下TCP，建議大家還是去看看 《TCP/IP 詳解一卷》。那個說的詳細(xì)。

HTTP 事務(wù)的時延

我們發(fā)送一個請求，其實在服務(wù)器處理的時間一般都不長，時間上的花費是在傳輸數(shù)據(jù)的路上。見下圖：

一條請求的時間

TCP連接的握手時延

握手需要發(fā)送三個TCP數(shù)據(jù)，這些是發(fā)送HTTP數(shù)據(jù)的準(zhǔn)備工作花費了很多時間，原本在發(fā)送3個TCP包前是不會發(fā)送HTTP請求的，但是后來發(fā)現(xiàn)在TCP握手的最后一個數(shù)據(jù)包可以利用發(fā)送數(shù)據(jù)，這種技術(shù)叫做捎帶。請求就變成這個樣子：

注意ACK已經(jīng)開始發(fā)送HTTP請求了

延遲確認(rèn)

書中表面：TCP傳輸?shù)臅r候都要接收方回發(fā)一個已收到的確認(rèn)信息（確認(rèn)報文），來告訴發(fā)送方，信息已經(jīng)收到，不需要再發(fā)送。
一個確認(rèn)報文是很小的，如果單獨作為一個TCP包發(fā)送顯得太浪費，所以操作系統(tǒng)會使用延時確認(rèn)技術(shù)，簡單的說就是在確認(rèn)收到信息的時候，不立馬發(fā)送確認(rèn)報文，而是等待一小段時間，等待有同地址的報文，并將其合并一起發(fā)送。類比現(xiàn)實生活很是形象。

TCP慢啟動

簡單的說就是： 開始發(fā)送TCP請求時不會立馬發(fā)送多個TCP報文，而是慢慢的并行的發(fā)送數(shù)量。比如成功發(fā)送一個之后，一次發(fā)送兩個，兩個成功之后。。。這樣是有好處的，比如可以避免多個TCP報文因為同一個原因發(fā)送失敗的而引發(fā)的性能浪費。

Connection

• 以上簡單的說了下TCP，我想看HTTP權(quán)威指南也不知道他想表達啥。建議看 TCP/IP詳解來了解TCP 這塊吧，后期我會邊玩我的MAC ，邊看書邊學(xué)這本書。

Connection 是HTTP的一個首部字段。
特點一：在Connection中包含的字段，不能被轉(zhuǎn)出到下一個地址。比如 Connection: name .那么name 這個首部就只能到下一個地址，活不到被下一個轉(zhuǎn)出。

請求方式

下面我們來聊聊web怎么玩HTTP

串行

這是最原始的時代，估計比我還老。這種方式就是發(fā)送一個HTTP請求等其全部完成之后再發(fā)送下一個請求。（stupid）
直接上圖吧，不嗶嗶：

連接-* 這里是建立TCP連接

并行

誰動能行到能并行，計算機本來就用的特性。
上例??的情況，我們分析，可以發(fā)現(xiàn)，1. 一次只發(fā)一個請求，浪費帶寬。2. 事務(wù)之間的聯(lián)系不一定要有先后關(guān)系，可以同時請求相互不影響。

模型圖：( 書中給的例子是一個HTML 和 3個圖片）

典型的頁面加載過程

并行的問題：

1. 帶寬可能有限，帶寬讓我們不可能高效的并行多個請求。
2. 性能，切換進程是需要花費性能的。
3. 服務(wù)器拒絕，你的機子牛逼了，服務(wù)器不干了。大家都一次發(fā)這么多請求，服務(wù)器撐不住的。你慢點。??

持久連接

并行連接其實并沒有本質(zhì)的提高連接的速度。它只是利用了計算機的進程功能，并沒有利用網(wǎng)絡(luò)知識。
非持續(xù)連接的問題：每次完成HTTP請求之后都要關(guān)閉TCP連接，但是我們的網(wǎng)站可能對同一個服務(wù)器發(fā)送多個請求，所以花費了很多時間在開啟關(guān)閉TCP連接的過程中。
HTTP1.1 就通過網(wǎng)絡(luò)知識本質(zhì)的提升了性能。
持續(xù)連接：在一個HTTP請求完成之后一段時間內(nèi)不關(guān)閉TCP的連接。
HTTP持久連接解決的問題：

1. 減少建立TCP連接的時延
2. 減少慢啟動的時延

上圖:

書中圖畫的不好，沒有把第一次建立連接，和慢啟動的優(yōu)化顯示出來

http1.0 持久連接 - Keep-alive

http1.0 如果想使用持久連接，會在請求報文中加入 Connection：keep-Alive ，如果服務(wù)器同意就會回發(fā)Connection：keep-alive .
一般 Connection：keep-alive 會和 keep-alive 首部一起使用 。如

Connection： Keep-Alive
Keep-Alive: max=5, timeout=120 ### 服務(wù)器還能支持保留多少個連接， 希望保持120秒的連接

keep-alive 的規(guī)則與限制

1. 持久連接建立起來之后，如果在這條連接上沒有在繼續(xù)發(fā) Connection：Keep-Alive 那么持久連接就會斷開。
2. 實體的主題部分必須代用正確的Content-Length，這樣就能讓另一端知道是報文的結(jié)束還是新報文的開始。占坑不是太懂
3. 啞代理問題

啞代理

啞代理的問題會出現(xiàn)在我們的網(wǎng)絡(luò)路線中出現(xiàn)一個不懂Keep-Alive機制又盲目轉(zhuǎn)發(fā)的代理的情況。
首先我們主機發(fā)送一份Keep-Alive的報文，代理接受到這樣一份報文，它不懂客戶端要保持連接，然后又轉(zhuǎn)發(fā)請求給服務(wù)器，服務(wù)器懂啊，就回了一份Connection：Keep-Alive的報文表示同意保持連接，中間代理又接受到了這樣的報文，還是不懂啊，再轉(zhuǎn)發(fā)給客戶端。這是客戶端和服務(wù)端都懂對方??。那么客戶端下一次就不會再發(fā)TCP握手?jǐn)?shù)據(jù)啦，直接發(fā)請求。但是這時代理就不干了，你不發(fā)建立連接的請求，不符合規(guī)矩，直接無視。尷尬的啞代理情況就出現(xiàn)了。
這種尷尬的情況書中沒有給出完備的解決方案。

HTTP1.1 默認(rèn)持續(xù)連接

HTTP1.1 持久連接的規(guī)章制度

1. HTTP1.1 不用發(fā)送Connection：keep-Alive 也是持久連接的
2. 只有在發(fā)送Connection: close 時才能斷開持久連接
3. 實體主體部分的長度與相應(yīng)的Content-Length一致，或者使用分塊出函數(shù)編碼方式。連接才能持久保持。占坑
4. HTTP1.1 代理必須能夠分別管理客戶端和服務(wù)器的持久連接
5. 一個客戶端最多只能與服務(wù)器或代理保持最多兩個持久連接

管道化連接

管道化在我的理解就是并行版的持久化連接請求。
就是在建立持久化連接后，在不等待上一條請求成功返回前就發(fā)送下一條請求。就是這么簡單。
上圖：

(b)為持久化串行請求

書中說了4點管道化的注意事項，但我感覺太過啰嗦，都是些開發(fā)者自己應(yīng)該注意的問題，不在我們的知識學(xué)習(xí)范圍內(nèi)不說了。

關(guān)于關(guān)閉連接

書中建議我們不適用管道化來發(fā)一些非冪等的請求，因為如果中間斷開了很難判斷是否服務(wù)端處理了請求，還是還沒收到就已經(jīng)斷開了連接。

記錄生活

我又戀愛了，又是那個女孩。異地戀。反而讓我覺得我應(yīng)該更快的成熟。原本想著畢業(yè)第一年好好的善待自己，看來還是要規(guī)劃下那少的可憐的薪水。