HTTP協議

在 OSI 七層模型中，HTTP 協議位于最頂層的應用層中。通過瀏覽器訪問網頁就直接使用了 HTTP 協議。使用 HTTP 協議時，客戶端首先與服務端的 80 端口建立一個 TCP 連接，然后在這個連接的基礎上進行請求和應答，以及數據的交換。

HTTPS協議

HTTP 有兩個常用版本，分別是 1.0 和 1.1。主要區別在于 HTTP 1.0 中每次請求和應答都會使用一個新的 TCP 連接，而從 HTTP 1.1 開始，運行在一個 TCP 連接上發送多個命令和應答。因此大幅度減少了 TCP 連接的建立和斷開，提高了效率。

由 HTTP 協議加載出來的網頁，通常使用 HTML 語言來描述，因此 HTML 也可以理解為網頁的一種數據格式。HTML 是一段純文本，可以指定網頁中的文字、圖像、音頻視頻圖片、鏈接，以及它們的顏色、位置等。無論計算機的底層結構如何，也無論網絡底層使用了哪些協議，使用 HTML 展示出來的效果基本上是一致的。從這個角度來說 HTML 位于 OSI 七層模型的表現層。

POST 請求和 GET 請求

HTTP 有八種請求（也稱方法），其中最常見的是 GET 請求和 POST 請求。
GET 請求通常用于查詢、獲取數據，而 POST 請求則用于發送數據，除了用途上的區別，它們還有以下這些不同：

• GET 請求可以被緩存，可以被收藏為書簽，但 POST 不行。
• GET 請求會保留在瀏覽器的歷史記錄中，POST 不會。
• GET 請求的長度有限制（不同的瀏覽器不一樣，大約在幾 Kb 左右），URL 的數據類型只能是 ASCII 字符，POST 請求沒有限制。
• GET 請求的參數在 URL 中，因此絕不能用 GET 請求傳輸敏感數據。POST 請求數據則寫在 HTTP 的請求頭中，安全性略高于 GET 請求。
• 在以下情況中，請使用 POST 請求：
  無法使用緩存文件（更新服務器上的文件或數據庫）
  向服務器發送大量數據（POST 沒有數據量限制）
  發送包含未知字符的用戶輸入時，POST 比 GET 更穩定也更可靠
  Post比Get安全性更高

注意：

POST 請求僅比 GET 請求略安全一點，它的數據不在 URL 中，但依然以明文的形式存放于 HTTP 的請求頭中。

Cookie 和 Session

HTTP 是一種無狀態的連接，客戶端每次讀取 web 頁面時，服務器都會認為這是一次新的會話。但有時候我們又需要持久保持某些信息，比如登錄時的用戶名、密碼，用戶上一次連接時的信息等。這些信息就由 Cookie 和 Session 保存。讓HTTP服務器和客戶之間傳遞狀態信息

使用 Cookie 的網站服務器為用戶產生一個唯一的識別碼。利用此識別碼，網站就能夠跟蹤該用戶在該網站的活動。

這兩者的根本性區別在于，cookie 保存在客戶端上，而 session 則保存在服務器中。由此我們還可以拓展出以下結論：

• cookie 相對來說不安全，瀏覽器可以分析本地的 cookie 進行 cookie 欺騙。
• session 可以設置超時時間，超過這個時間后就失效，以免長期占用服務端內存。
• 單個 cookie 的大小有限制（4 Kb），每個站點的 cookie 數量一般也有限制（20個）。
• 客戶端每次都會把 cookie 發送到服務端，因此服務端可以知道 cookie，但是客戶端不知道 session。
• 當服務器接收到 cookie 后，會根據 cookie 中的 SessionID 來找到這個客戶的 session。如果沒有，則會生成一個新的 SessionID 發送給客戶端。

HTTP響應消息中的狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：

1xx : 請求已經接受，需要繼續處理。
2xx : 請求已經被服務器接收、理解 
      200 OK 
      請求已成功，請求所希望的響應頭或數據體將隨此響應返回。
3xx : 重定向--要完成請求必須進行更進一步的操作
4xx : 客戶端錯誤--請求有語法錯誤或請求無法實現
      400 bad request 由于包含語法錯誤，當前請求無法被服務器理解。
      除非進行修改，否則客戶端不應該重復提交這個請求。 
      401 unauthorized 當前請求需要用戶驗證。 
      403 Forbbiden 服務器已經理解請求，但是拒絕執行它。 
      404 Not Found 請求失敗，請求所希望得到的資源未被在服務器上發現。
       沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的 
      405 Method Not Allowed 請求行中指定的請求方法不能被用于請求相應的資源。 
      該響應必須返回一個 Allow 頭信息用以表示出當前資源能夠接受的請求方法的列表。 
      鑒于 PUT，DELETE 方法會對服務器上的資源進行寫操作， 
      因而絕大部分的網頁服務器都不支持或者在默認配置下不允許上述請求方法， 
      對于此類請求均會返回 405 錯誤。
5xx : 服務器錯誤 
      503 Service Unavailable 
      由于臨時的服務器維護或者過載，服務器當前無法處理請求。 
      這個狀況是臨時的，并且將在一段時間以后恢復。 
      如果能夠預計延遲時間，那么響應中可以包含一個 Retry-After 頭用以標明這個延遲時間。 
      如果沒有給出這個 Retry-After 信息，那么客戶端應當以處理 500 響應的方式處理它。 

      505 HTTP Version Not Supported 
      服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本。

加密

加密分為兩種，對稱加密和非對稱加密。在解釋這兩者的含義前，先來看一下簡單的加密、解密過程：

所謂的對稱，就是指加密秘鑰和解密秘鑰相同，而非對稱自然就是指兩者不同。
舉一個對稱加密的例子。假設這里的加密算法是加法，解密算法是減法。如果明文數據是 10，秘鑰是 1，那么加密數據就是10 + 1 = 11，如果接收方不知道秘鑰，就不知道密文 11 應該減去幾。反之，如果接收方知道秘鑰是 1，就可以通過11 - 1 = 10
計算出明文數據。
常見的一個非對稱加密算法是 RSA 算法，它主要利用了“兩個素數求乘積容易，但是將乘積分解為兩個素數很難”這一思想。它的具體原理不在本文討論范圍，有興趣的讀者可以查看文章末尾的參考文章。
在非對稱加密中，利用公鑰加密的數據能且只能通過私鑰解密，通過私鑰加密的數據能且只能通過公鑰解密。
對稱加密的優點在于速度快，但是假設秘鑰由服務器保存，如何安全的讓客戶端得到秘鑰是需要解決的問題。因此實際的網絡傳輸中，通常使用對稱加密與非對稱加密結合的方式，服務端通過非對稱加密將對稱秘鑰發給客戶端。此后雙方使用這個對稱密鑰進行通信。

HTTPS

我們知道 HTTP 協議直接使用了 TCP 協議進行數據傳輸。由于數據沒有加密，都是直接明文傳輸，所以存在以下三個風險：
竊聽風險：第三方節點可以獲知通信內容。
篡改風險：第三方節點可以修改通信內容。
冒充風險：第三方節點可以冒充他人身份參與通信。

比如你在手機上打開應用內的網頁時，有時會看到網頁底部彈出了廣告，這實際上就說明你的 HTTP 內容被竊聽、并篡改了。
HTTPS 協議旨在解決以上三個風險，因此它可以：
保證所有信息加密傳輸，無法被第三方竊取。
為信息添加校驗機制，如果被第三方惡意破壞，可以檢測出來。
配備身份證書，防止第三方偽裝參與通信。

HTTPS 的結構如圖所示：

HTTPS 協議

可見它僅僅是在 HTTP 和 TCP 之間新增了一個 TLS/SSL 加密層，這也印證了一句名言：“一切計算機問題都可以通過添加中間層解決”。
使用 HTTPS 時，服務端會將自己的證書發送給客戶端，其中包含了服務端的公鑰?；诜菍ΨQ加密的傳輸過程如下：
客戶端使用公鑰將信息加密，密文發送給服務端
服務端用自己的私鑰解密，再將返回數據用私鑰加密發回客戶端
客戶端用公鑰解密

HTTP和HTTPS的區別

• HTTP是HTTP協議運行在TCP之上。所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份。
• HTTPS是HTTP運行在SSL/TLS之上，SSL/TLS運行在TCP之上。所有傳輸的內容都經過加密，加密采用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。此外客戶端可以驗證服務器端的身份，如果配置了客戶端驗證，服務器方也可以驗證客戶端的身份。
  -HTTPS協議需要到ca申請證書，一般免費證書很少，需要交費。
• HTTP是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議
• HTTP和HTTPS使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。
• HTTP的連接很簡單,是無狀態的
• HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全

TCP如何保證可靠傳輸？

• TCP如何保證可靠傳輸
  1. 數據包校驗
  2. 超時重傳機制
  3. 應答機制
  4. 對失序數據包重排序
  5. TCP還能提供流量控制

TCP狀態轉移圖

TCP狀態轉移圖

三次握手

三次握手及四次揮手過程

• 3次握手過程狀態：
• LISTEN: 這個也是非常容易理解的一個狀態，表示服務器端的某個SOCKET處于監聽狀態，可以接受連接了。
• SYN_SENT: 當客戶端SOCKET執行CONNECT連接時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，并等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。（發送端）
• SYN_RCVD: 這個狀態與SYN_SENT遙想呼應這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程序，故意將三次TCP握手過程中最后一個 ACK報文不予發送。因此這種狀態時，當收到客戶端的ACK報文后，它會進入到ESTABLISHED狀態。（服務器端）
• ESTABLISHED：這個容易理解了，表示連接已經建立了。
• 為什么TCP連接需要三次握手，兩次不可以嗎，為什么
  • 為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。
  • 例子 （發送連接請求延遲到達服務器端）

“已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發出的一個新的連接請求。于是就向client發出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發出確認，新的連接就建立了。由于現在client并沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，并一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由于收不到確認，就知道client并沒有要求建立連接?！?/p>

• 三次握手完成兩個重要的功能，既要雙方做好發送數據的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被發送和確認。
• 把三次握手改成僅需要兩次握手，死鎖是可能發生的（服務器端確認連接的包丟失）

考慮計算機S和C之間的通信，假定C給S發送一個連接請求分組，S收到了這個分組，并發送了確認應答分組。按照兩次握手的協定，S認為連接已經成功地建立了，可以開始發送數據分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S是否已準備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認為連接還未建立成功，將忽略S發來的任何數據分組，只等待連接確認應答分組。而S在發出的分組超時后，重復發送同樣的分組。這樣就形成了死鎖。

• 三次握手的漏洞及攻擊
  • 如果客戶端不斷的發送請求連接會怎樣？
    服務器端回為每個請求創建一個鏈接，然后向client端發送創建鏈接時的回復，然后進行等待客戶端發送第三次握手數據包，這樣會白白浪費資源
• DDos攻擊
  簡單的說就是想服務器發送鏈接請求，首先進行
  第一步：客戶端向服務器端發送連接請求數據包（1）
  第二步：服務器向客戶端回復連接請求數據包（2），然后服務器等待客戶端發送tcp/ip鏈接的第三步數據包(3)
  第三步：如果客戶端不向服務器端發送最后一個數據包(3)，則服務器須等待30s到2min中才能將此鏈接進行關閉。當大量的請求只進行到第二步，而不進行第三步，服務器又大量的資源等待第三個數據包。則造成DDos攻擊。

DDoS究竟如何攻擊?目前最流行也是最好用的攻擊方法就是使用SYN-Flood進行攻擊，SYN-Flood也就是SYN洪水攻擊。SYN-Flood不會完成TCP三次握手的第三步，也就是不發送確認連接的信息給服務器。這樣，服務器無法完成第三次握手，但服務器不會立即放棄，服務器會不停的重試并等待一定的時間后放棄這個未完成的連接，這段時間叫做SYN timeout，這段時間大約30秒-2分鐘左右。

若是一個用戶在連接時出現問題導致服務器的一個線程等待1分鐘并不是什么大不了的問題，但是若有人用特殊的軟件大量模擬這種情況，那后果就可想而知了。一個服務器若是處理這些大量的半連接信息而消耗大量的系統資源和網絡帶寬，這樣服務器就不會再有空余去處理普通用戶的正常請求(因為客戶的正常請求比率很小)。這樣這個服務器就無法工作了，這種攻擊就叫做:SYN-Flood攻擊。
SYN-FLOOD是一種常見的DDos攻擊，拒絕服務攻擊。通過網絡服務所在的端口發送大量偽造原地址的攻擊報文，發送到服務端，造成服務端上的半開連接隊列被占滿，從而阻止其他用戶進行訪問。它的數據報特征是大量syn包，并且缺少最后一步的ACK回復。
攻擊原理：攻擊者首先偽造地址，對服務器發起syn請求，服務器回應syn+ACK，而真實的IP會認為我沒有發送請求，不做回應，而服務端沒有收到回應，服務器就不知道是否發送成功，默認情況下重試5次 syn_retries，這樣的話，對于服務器內存和帶寬有很大的消耗。

• 解決SYN FLOOD方法
• (1).無效連接監控
  不停監視半開連接和不活動連接，當半開連接數和不活動連接數到達一定值時候，就釋放系統資源。 傷敵1000，自損8000
• (2).延緩TCB方法
  SYN FLOOD的關鍵是利用了，syn數據報一到，系統就分配TCB資源。
  那么我們有兩種方法資源問題：
  • Syn cache
    這種技術在收到Syn時不急著分配TCB，而是先回應一個ACK報文，并在一個專用的HASH表中保存這種連接，直到收到正確的ACK，才分配TCB。
  • Syn Cookie
    用一種特殊的算法生成sequence number，算法考慮到對方的信息和己方信息，收到對方的ACK報文后，驗證之后才決定是否生成TCB
• DDos預防(這種攻擊的特點是它利用了TCP/IP協議的漏洞，除非你不用TCP/IP，才有可能完全抵御住DDoS攻擊)
  • 確保服務器的系統文件是最新版本，并及時更新系統補丁
  • 關閉不必要的服務
  • 限制同時打開SYN的半連接數目
  • 縮短SYN半連接的time out時間
  • 正確設置防火墻
  • 禁止對主機的非開放服務的訪問
  • 限制特定IP短地址的訪問
  • 啟用防火墻的防DDos的屬性
  • 嚴格限制對外開放的服務器的向外訪問
  • 運行端口映射程序禍端口掃描程序，要認真檢查特權端口和非特權端口。
    認真檢查網絡設備和主機/服務器系統的日志。只要日志出現漏洞或是時間變更，那這臺機器就可能遭到了攻擊。
  • 限制在防火墻外與網絡文件共享。這樣會給黑客截取系統文件的機會，主機的信息暴露給黑客，無疑是給了對方入侵的機會。

四次揮手

四次揮手過程

• 四次揮手過程狀態:
  • FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連接，向對方發送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方回應ACK報文后，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。（主動方）
• FIN_WAIT_2：實際上FIN_WAIT_2狀態下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你(ACK信息)，稍后再關閉連接。（主動方）TIME_WAIT: 表示收到了對方的FIN報文，并發送出了ACK報文，就等2MSL后即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態，而無須FIN_WAIT_2狀態。（主動方）
• FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你(ACK信息)，稍后再關閉連接。（主動方）TIME_WAIT: 表示收到了對方的FIN報文，并發送出了ACK報文，就等2MSL后即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態，而無須經FIN_WAIT_2狀態。（主動方）
• CLOSING（比較少見）: 這種狀態比較特殊，實際情況中應該是很少見，屬于一種比較罕見的例外狀態。正常情況下，當你發送FIN報文后，按理來說是應該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文后，并沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什么情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close一個SOCKET的話，那么就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連接。
• CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。當對方close一個SOCKET后發送FIN報文給自己，你系統毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數據發送給對方，如果沒有的話，那么你也就可以 close這個SOCKET，發送FIN報文給對方，也即關閉連接。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連接。（被動方）
• LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文后，最后等待對方的ACK報文。當收到ACK報文后，也即可以進入到CLOSED可用狀態了。（被動方）

• CLOSED: 表示連接中斷。

  
  
  四次揮手過程圖看著也行
• 為什么四次揮手
  解釋原因：

TCP建立連接要進行3次握手,而斷開連接要進行4次,這是由于TCP的半關閉造成的,因為TCP連接是全雙工的(即數據可在兩個方向上同時傳遞)所以進行關閉時每個方向上都要單獨進行關閉,這個單方向的關閉就叫半關閉.
關閉的方法是一方完成它的數據傳輸后,就發送一個FIN來向另一方通告將要終止這個方向的連接.當一端收到一個FIN,它必須通知應用層TCP連接已終止了這個方向的數據傳送,發送FIN通常是應用層進行關閉的結果.

另一種解釋：

這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文里來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文和FIN報文多數情況下都是分開發送的。

• 為什么TIME_WAIT狀態還需要等2MSL后才能返回到CLOSED狀態？

  • 什么是2MSL？
    MSL即Maximum Segment Lifetime，也就是報文最大生存時間，引用《TCP/IP詳解》中的話：“它(MSL)是任何報文段被丟棄前在網絡內的最長時間?！蹦敲?，2MSL也就是這個時間的2倍，當TCP連接完成四個報文段的交換時，主動關閉的一方將繼續等待一定時間(2-4分鐘)，即使兩端的應用程序結束。
    例如在上面的telnet程序客戶端關閉后，使用netstat查看的結果:
    C:\>netstat -na | find "172.29.21.25"TCP 172.29.132.60:2795 172.29.21.25:23 TIME_WAIT

• 為什么需要這個2MSL：

  • 第一，雖然雙方都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網絡是不可靠的，你無法保證你最后發送的ACK報文會一定被對方收到，因此對方處于LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。
  • 第二，報文可能會被混淆，意思是說，其他時候的連接可能會被當作本次的連接。

直接引用《The TCP/IP Guide》的說法：The second is to provide a “buffering period” between the end of this connection and any subsequent ones. If not for this period, it is possible that packets from different connections could be mixed, creating confusion.

 **當某個連接的一端處于TIME_WAIT狀態時，該連接將不能再被使用。事實上，對于我們比較有現實意義的是，這個端口將不能再被使用。某個端口處于TIME_WAIT狀態(其實應該是這個連接)時，這意味著這個TCP連接并沒有斷開(完全斷開)，那么，如果你bind這個端口，就會失敗。**對于服務器而言，如果服務器突然crash掉了，那么它將無法在2MSL內重新啟動，因為bind會失敗。解決這個問題的一個方法就是設置socket的SO_REUSEADDR選項。這個選項意味著你可以重用一個地址。

TCP和UDP區別？如何改進TCP

• TCP和UDP區別
• UDP 是無連接的，即發送數據之前不需要建立連接。
• UDP?使用盡最大努力交付，即不保證可靠交付，同時也不使用擁塞控制。
• UDP 是面向報文的。UDP 沒有擁塞控制，很適合多媒體通信的要求。
• UDP 支持一對一、一對多、多對一和多對多的交互通信。
• UDP 的首部開銷小，只有 8 個字節。
• TCP 是面向連接的運輸層協議。
• 每一條 TCP 連接只能有兩個端點(endpoint)，每一條 TCP?連接只能是點對點的（一對一）。
• TCP 提供可靠交付的服務。
• TCP?提供全雙工通信。
• TCP是面向字節流。
• 首部最低20個字節。
• TCP加快傳輸效率的方法 ：采取一塊確認的機制

TCP：面向連接、字節流和可靠傳輸
UDP:無連接、數據包、不可靠傳輸
字節流的概念：發送端執行的寫操作次數和接收端執行的讀操作次數之間沒有任何數量關系，這就是字節流的概念

滑動窗口算法

http://coolshell.cn/articles/11609.html

TCP的擁塞控制 – Congestion Handling

• 在計算機網絡中的鏈路容量（帶寬）、交換結點的緩存和處理機等，都是網絡的資源。在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變壞。 -- 這種情況叫做擁塞。
• 出現資源擁塞的條件：
  對資源需求的總和 > 可用資源
• 擁塞控制與流量控制的關系
  擁塞控制所要做的都有一個前提，就是網絡能夠承受現有的網絡符合。
• 擁塞控制與流量控制的區別
• 擁塞控制是一個全局性的過程，涉及到所有的主機、所有的路由器，以及與降低網絡傳輸性能有關的所有因素。
• 流量控制往往指在給定的發送端和接收端之間的點對點通信量的控制
  流量控制所要做的是抑制發送端發送數據的速率，以便使接收端來得及接收。
• 擁塞控制的方法
  1）慢啟動，2）擁塞避免，3）擁塞發生，4）快速恢復。

從輸入網址到獲得頁面的過程

• 查詢DNS，獲取域名對應的IP地址
• 瀏覽器搜索自身的DNS緩存
• 搜索操作系統的DNS緩存
• 讀取本地的HOST文件
• 發起一個DNS的系統調用
• 寬帶運營服務器查看本身緩存
• 運營商服務器發起一個迭代DNS解析請求
• 瀏覽器獲得域名對應的IP地址后，發起HTTP三次握手
• TCP/IP連接建立起來后，瀏覽器就可以向服務器發送HTTP請求了
• 服務器接受到這個請求，根據路徑參數，經過后端的一些處理生成HTML頁面代碼返回給瀏覽器
• 瀏覽器拿到完整的HTML頁面代碼開始解析和渲染，如果遇到引用的外部JS，CSS,圖片等靜態資源，它們同樣也是一個個的HTTP請求，都需要經過上面的步驟
• 瀏覽器根據拿到的資源對頁面進行渲染，最終把一個完整的頁面呈現給用戶

用戶點擊鼠標后所發生的事件

(1) 瀏覽器分析超鏈指向頁面的 URL。
(2) 瀏覽器向 DNS 請求解析 www.tsinghua.edu.cn 的 IP 地址。
(3) 域名系統 DNS 解析出清華大學服務器的 IP 地址。
(4) 瀏覽器與服務器建立 TCP 連接
(5) 瀏覽器發出取文件命令： GET /chn/yxsz/index.htm。
(6) 服務器給出響應，把文件 index.htm 發給瀏覽器。
(7) TCP 連接釋放。
(8) 瀏覽器顯示“清華大學院系設置”文件 index.htm 中的所有文本。

長連接和短連接

http://www.codeceo.com/article/http-long-connect.html
1. HTTP協議與TCP/IP協議的關系
HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP屬于應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另一端收到發端發出的所有包，并且順序與發出順序一致。TCP有可靠，面向連接的特點。
2. 如何理解HTTP協議是無狀態的

使用HTTP協議，每當有新的請求發送時，就會有對應的新響應產生。協議本身并不保留之前一切的請求或響應報文的信息。這是為了更快地處理大量事務，確保協議的可伸縮性，而特意把HTTP協議設計的如此簡單。
無狀態-->導致網站無法保存用戶的狀態-->引入Cookie技術
有了Cookie再用HTTP協議通信，就可以管理狀態了

HTTP協議是無狀態的，指的是協議對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態。也就是說，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯系。HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）。
3. 什么是長連接、短連接？
在HTTP/1.0中，默認使用的是短連接。也就是說，瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。
但從 HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭有加入這行代碼：

Connection:keep-alive

在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的 TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。

TCP協議總結--停止等待協議,連續ARQ協議,滑動窗口協議

http://www.cnblogs.com/yangbodong/p/4964698.html

圖解HTTP讀書筆記

特別全面?。。?br> https://segmentfault.com/a/1190000004869057
這個也還可以
https://mozillazg.com/2015/08/tujie-http-note.html