http://www.2cto.com/net/201604/501018.html

評論：講解的你內容不多，但內容很準確，很必要。一句話：精華。

tcp/ip基礎知識

TCP/IP全稱是Transmission Control Protocol/Internet Protocol。

IP地址共32位，4字節。

IP地址分爲兩部分：網絡標識和主機標識。

A類IP地址：第一段爲網絡標識，剩下三段爲主機標識。網絡地址最高位必須爲零。網絡標識長度爲7位，主機標識長度爲24位。A類網絡的主機數最多可以達到1600多臺。

B類IP地址：第一、二段位網絡標識，第三、四段爲主機標識。網絡地址最高位必須爲10。網絡標識長度爲14位，主機標識長度位16位。每個網絡最多能容納6萬多臺主機。

C類IP地址：前三段位網絡標識，剩下一段爲主機標識。網絡地址最高位必須爲110。網絡標識長度爲21位，主機標識長度爲8位。每個網絡最多容納254臺主機。

子網掩碼也是32位的一個IP地址，它的用途是識別本網絡內的計算機。兩臺不同主機的IP地址同時與子網掩碼進行AND運算，如果得出結果相同，則說明這兩臺計算機處於同一個子網內，可以進行直接通信。

域名的構成：主機名＋機構名＋網絡名＋最高層域名。

傳輸層的核心協議是TCP和UDP。

TCP提供一對一的、面向連接的可靠通信服務。TCP建立連接，對發送的數據包進行排序和確認，並恢復在傳輸過程中丟失的數據包。與TCP不同，UDP提供一對一或一對多的、無連接的不可靠通信服務。
不論是TCP/IP還是在OSI參考模型中，任意相鄰兩層的下層爲服務提供者，上層爲服務調用者。下層爲上層提供的服務可分爲兩類：面向連接服務和無連接服務。

面向連接的網絡服務

面向連接的網絡服務又稱爲虛電路（Virtual Circuit）服務，它具有網絡連接建立、數據傳輸和網絡連接釋放三個階段。是按順序傳輸可靠的報文分組方式，適用於指定對象、長報文、會話型傳輸要求。
面向連接服務以電話系統爲模式。要和某個人通話，首先拿起電話，撥號碼，通話，然後掛斷。同樣在使用面向連接的服務時，用戶首先要建立連接，使用連接，然後釋放連接。連接本質上像個管道：發送者在管道的一端放入物體，接收者在另一端按同樣的次序取出物體；其特點是收發的數據不僅順序一致，而且內容也相同。–類似打電話

無連接的網絡服務

無連接網絡服務的兩實體之間的通信不需要事先建立好一個連接。無連接網絡服務有3種類型：數據報（Datagram）、確認交付（Confirmed Delivery）與請求回答（Request reply）。
無連接服務以郵政系統爲模式。每個報文（信件）帶有完整的目的地址，並且每一個報文都獨立於其他報文，由系統選定的路線傳遞。在正常情況下，當兩個報文發往同一目的地時，先發的先到。但是，也有可能先發的報文在途中延誤了，後發的報文反而先收到；而這種情況在面向連接的服務中是絕對不可能發生的。–類似發短信

傳輸控制協議（TCP）

TCP全稱是Transmission Control Protocol，中文名爲傳輸控制協議，它可以提供可靠的、面向連接的網絡數據傳遞服務。傳輸控制協議主要包含下列任務和功能：

tcp功能

對程序發送的大塊數據進行分段和重組。
確保正確排序及按順序傳遞分段的數據。
通過計算校驗和，進行傳輸數據的完整性檢查。
根據數據是否接收成功發送肯定消息。通過使用選擇性確認，也對沒有收到的數據發送否定確認。
爲必須使用可靠的、基於會話的數據傳輸程序，如客戶端/服務器數據庫和電子郵件程序，提供首選傳輸方法。

TCP工作原理

首先發送方主機向接收方主機發起一個建立連接的同步（SYN）請求；
接收方主機在收到這個請求後向發送方主機回覆一個同步/確認（SYN/ACK）應答；
發送方主機收到此包後再向接收方主機發送一個確認（ACK），此時TCP連接成功建立.
一旦初始的三次握手完成，在發送和接收主機之間將按順序發送和確認段。關閉連接之前，TCP使用類似的握手過程驗證兩個主機是否都完成發送和接收全部數據。
完成三次握手，客戶端與服務器開始傳送數據。

udp介紹

UDP全稱是User Datagram Protocol，中文名爲用戶數據報協議。UDP 提供無連接的網絡服務，該服務對消息中傳輸的數據提供不可靠的、最大努力傳送。這意味着它不保證數據報的到達，也不保證所傳送數據包的順序是否正確。
我最初就有一個疑惑：“既然UDP是一種不可靠的網絡協議，那麼還有什麼使用價值或必要呢？”
在有些情況下UDP可能會變得非常有用。因爲UDP具有TCP所望塵莫及的速度優勢。雖然TCP中植入了各種安全保障功能，但是在實際執行的過程中會佔用大量的系統開銷，無疑使速度受到嚴重的影響。反觀UDP由於排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大地降低了執行時間，使速度得到了保證。

TCP與端口號

TCP和UDP都是IP層面的傳輸協議，是IP與上層之間的處理接口。TCP和UDP端口號被設計來區分運行在單個設備上的多重應用程序的IP地址。由於同一臺計算機上可能會運行多個網絡應用程序，所以計算機需要確保目標計算機上接收源主機數據包的軟件應用程序的正確性，以及響應能夠被髮送到源主機的正確應用程序上。該過程正是通過使用TCP或UDP端口號來實現的。
－－即每一個應用都會在網卡上註冊一個端口號用來區分同一臺設備上應用的之間的通信

在TCP和UDP頭部分，有“源端口”和“目標端口”段，主要用於顯示發送和接收過程中的身份識別信息。IP 地址和端口號合在一起被稱爲“套接字”。TCP端口比較複雜，其工作方式與UDP端口不同。UDP端口對於基於UDP的通信作爲單一消息隊列和網絡端點來操作，而所有TCP通信的終點都是唯一的連接。每個TCP連接由兩個端點唯一識別。由於所有TCP連接由兩對 IP 地址和TCP端口唯一識別（每個所連主機都有一個地址/端口對），因此每個TCP服務器端口都能提供對多個連接的共享訪問

HTTP協議

超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最爲廣泛的一種網絡協議。
http協議規定了客戶端和服務器之間的數據傳輸格式.

http優點:

簡單快速:
http協議簡單,通信速度很快;
靈活:
http協議允許傳輸任意類型的數據;
短連接:
http協議限制每次連接只處理一個請求,服務器對客戶端的請求作出響應後,馬上斷開連接.這種方式可以節省傳輸時間.

http協議的使用過程

請求:客戶端向服務器索要數據.

http協議規定:一個完整的http請求包含'請求行','請求頭','請求體'三個部分;

請求行：包含了請求方法,請求資源路徑,http協議版本. "GET /resources/images/ HTTP/1.1"
請求頭:包含了對客戶端的環境描述,客戶端請求的主機地址等信息.
Accept: text/html ( 客戶端所能接收的數據類型 )
Accept-Language: zh-cn ( 客戶端的語言環境 )
Accept-Encoding: gzip( 客戶端支持的數據壓縮格式 )
Host: m.baidu.com( 客戶端想訪問的服務器主機地址 )
User-Agent: Mozilla/5.0(Macintosh;Intel Mac OS X10.10 rv:37.0) Gecko/20100101Firefox/37.0( 客戶端的類型,客戶端的軟件環境 )
請求體:客戶端發給服務器的具體數據,比如文件/圖片等.

響應:服務器返回客戶端想要的數據

http協議規定:一個完整的http響應包含'狀態行','響應頭','實體內容'三個部分;

狀態行:包含了http協議版本,狀態嗎,狀態英文名稱.
"HTTP/1.1 200 OK"
響應頭:包含了對服務器的描述,對返回數據的描述.
Content-Encoding: gzip(服務器支持的數據壓縮格式) Content-Length: 1528(返回數據的長度)
Content-Type:application/xhtml+xml;charset=utf-8(返回數據的類型)
Date: Mon,15Jun201509:06:46GMT(響應的時間) Server: apache (服務器類型)
實體內容:服務器返回給客戶端的具體數據(圖片/html/文件...).

http方法

http協議定義了很多方法對應不同的資源操作,其中最常用的是GET和POST方法。
eg：GET、POST、OPTIONS、HEAD、PUT、DELETE、TRACE、CONNECT、PATCH
增:PUT
刪:DELETE
改:POST
查:GET
因爲GET和POST可以實現上述所有操作,所以,在現實開發中,GET和POST方法使用的最爲廣泛，除此以外HEAD請求使用頻率也比較高；

GET
在請求URL後面以?的形式跟上發給服務器的參數,參數以”參數名”=”參數值”的形式拼接,多個參數之間用&分隔;
GET的本質是從服務器得到數據,效率更高.並且GET請求可以被緩存.
注意:GET的長度是有限制的,不同的瀏覽器有不同的長度限制,一般在2~8K之間;
POST
POST的本質是向服務器發送數據,也可以獲得服務器處理之後的結果,效率不如GET.POST請求不可以被緩存,每次刷新之後都需要重新提交表單.
發送給服務器的參數全部放在’請求體’中;
理論上,POST傳遞的數據量沒有限制.
注意:所有涉及到用戶隱私的數據(密碼/銀行卡號等…)都要用POST的方式傳遞.
HEAD
HEAD方法通常用在下載文件之前,獲取遠程服務器的文件信息!相比於GET請求,不會下載文件數據,只獲得響應頭信息!
一般,使用HEAD方法的目的是提前告訴用戶下載文件的信息,由用戶確定是否下載文件!所以, HEAD方法,最好發送同步請求!

響應消息

1xx:信息響應類，表示接收到請求並且繼續處理
2xx:處理成功響應類，表示動作被成功接收、理解和接受
3xx:重定向響應類，爲了完成指定的動作，必須接受進一步處理
4xx:客戶端錯誤，客戶請求包含語法錯誤或者是不能正確執行
5xx:服務端錯誤，服務器不能正確執行一個正確的請求;

狀態碼

1xx:信息
消息
描述
100 Continue
服務器僅接收到部分請求，但是一旦服務器並沒有拒絕該請求，客戶端應該繼續發送其餘的請求。
101 Switching Protocols
服務器轉換協議：服務器將遵從客戶的請求轉換到另外一種協議。
2xx:成功
消息
描述
200 OK
請求成功（其後是對GET和POST請求的應答文檔。）
201 Created
請求被創建完成，同時新的資源被創建。
202 Accepted
供處理的請求已被接受，但是處理未完成。
203 Non-authoritative Information
文檔已經正常地返回，但一些應答頭可能不正確，因爲使用的是文檔的拷貝。
204 No Content
沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。
205 Reset Content
沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。
206 Partial Content
客戶發送了一個帶有Range頭的GET請求，服務器完成了它。
3xx:重定向
消息
描述
300 Multiple Choices
多重選擇。鏈接列表。用戶可以選擇某鏈接到達目的地。最多允許五個地址。
301 Moved Permanently
所請求的頁面已經轉移至新的url。
302 Found
所請求的頁面已經臨時轉移至新的url。
303 See Other
所請求的頁面可在別的url下被找到。
304 Not Modified
未按預期修改文檔。客戶端有緩衝的文檔併發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩衝的文檔還可以繼續使用。
305 Use Proxy
客戶請求的文檔應該通過Location頭所指明的代理服務器提取。
306 Unused
此代碼被用於前一版本。目前已不再使用，但是代碼依然被保留。
307 Temporary Redirect
被請求的頁面已經臨時移至新的url。
4xx:客戶端錯誤
消息
描述
400 Bad Request
服務器未能理解請求。
401 Unauthorized
被請求的頁面需要用戶名和密碼。
401.1
登錄失敗。
401.2
服務器配置導致登錄失敗。
401.3
由於 ACL 對資源的限制而未獲得授權。
401.4
篩選器授權失敗。
401.5
ISAPI/CGI 應用程序授權失敗。
401.7
訪問被 Web 服務器上的 URL 授權策略拒絕。這個錯誤代碼爲 IIS 6.0 所專用。
402 Payment Required
此代碼尚無法使用。
403 Forbidden
對被請求頁面的訪問被禁止。
403.1
執行訪問被禁止。
403.2
讀訪問被禁止。
403.3
寫訪問被禁止。
403.4
要求 SSL。
403.5
要求 SSL 128。
403.6
IP 地址被拒絕。
403.7
要求客戶端證書。
403.8
站點訪問被拒絕。
403.9
用戶數過多。
403.10
配置無效。
403.11
密碼更改。
403.12
拒絕訪問映射表。
403.13
客戶端證書被吊銷。
403.14
拒絕目錄列表。
403.15
超出客戶端訪問許可。
403.16
客戶端證書不受信任或無效。
403.17
客戶端證書已過期或尚未生效。
403.18
在當前的應用程序池中不能執行所請求的 URL。這個錯誤代碼爲 IIS 6.0 所專用。
403.19
不能爲這個應用程序池中的客戶端執行 CGI。這個錯誤代碼爲 IIS 6.0 所專用。
403.20
Passport 登錄失敗。這個錯誤代碼爲 IIS 6.0 所專用。
404 Not Found
服務器無法找到被請求的頁面。
404.0
（無）–沒有找到文件或目錄。
404.1
無法在所請求的端口上訪問 Web 站點。
404.2
Web 服務擴展鎖定策略阻止本請求。
404.3
MIME 映射策略阻止本請求。
405 Method Not Allowed
請求中指定的方法不被允許。
406 Not Acceptable
服務器生成的響應無法被客戶端所接受。
407 Proxy Authentication Required
用戶必須首先使用代理服務器進行驗證，這樣請求才會被處理。
408 Request Timeout
請求超出了服務器的等待時間。
409 Conflict
由於衝突，請求無法被完成。
410 Gone
被請求的頁面不可用。
411 Length Required
"Content-Length" 未被定義。如果無此內容，服務器不會接受請求。
412 Precondition Failed
請求中的前提條件被服務器評估爲失敗。
413 Request Entity Too Large
由於所請求的實體的太大，服務器不會接受請求。
414 Request-url Too Long
由於url太長，服務器不會接受請求。當post請求被轉換爲帶有很長的查詢信息的get請求時，就會發生這種情況。
415 Unsupported Media Type
由於媒介類型不被支持，服務器不會接受請求。
416 Requested Range Not Satisfiable
服務器不能滿足客戶在請求中指定的Range頭。
417 Expectation Failed
執行失敗。
423
鎖定的錯誤。
5xx:服務器錯誤
消息
描述
500 Internal Server Error
請求未完成。服務器遇到不可預知的情況。
500.12
應用程序正忙於在 Web 服務器上重新啓動。
500.13
Web 服務器太忙。
500.15
不允許直接請求 Global.asa。
500.16
UNC 授權憑據不正確。這個錯誤代碼爲 IIS 6.0 所專用。
500.18
URL 授權存儲不能打開。這個錯誤代碼爲 IIS 6.0 所專用。
500.100
內部 ASP 錯誤。
501 Not Implemented
請求未完成。服務器不支持所請求的功能。
502 Bad Gateway
請求未完成。服務器從上游服務器收到一個無效的響應。
502.1
CGI 應用程序超時。　·
502.2
CGI 應用程序出錯。
503 Service Unavailable
請求未完成。服務器臨時過載或當機。
504 Gateway Timeout
網關超時。
505 HTTP Version Not Supported
服務器不支持請求中指明的HTTP協議版本。

面試之路-TCP/IP/HTTP概述