TCP/IP的分層管理
應用層
應用層決定了向用戶提供應用服務時通信的活動。
TCP/IP協議族內預存了各類通用的應用服務。如，FTP（File Transfer Protocol)和DNS(Domain Name System,域名系統)服務就是其中兩類。
HTTP協議也處於該層。
傳輸層
傳輸層對上層應用層，提供處於網絡連接中的兩臺計算機之間的數據傳輸。
在傳輸層有兩個性質不同的協議：TCP(Transmission Control Protocol，傳輸控制協議)和UDP(User Data Protocol，用戶數據報協議)。
網絡層
網絡層用來處理在網絡上流動的數據包。數據包是網線傳輸的最小數據單位。該層規定了通過怎樣的途徑（所謂的傳輸線路）到達對方計算機，並把數據包傳送給對方。
與對方計算機之間通過多臺計算機或網絡設備進行傳輸時，網絡層所起的作用就是在衆多的選項內選擇一條傳輸路線。
鏈路層
用來處理連接網絡的硬件部分。包括控制操作系統、硬件的設備驅動、NIC（Network interface Card，網絡適配器，即網卡），及光纖等物理可見部分。硬件上的範疇均在鏈路層的作用範圍之內。
通信傳輸流
利用TCP/IP協議族進行網絡通信時，會通過分層順序與對方進行通信。發送端從應用層往下走，接收端則往應用層往上走。
我們用HTTP舉例說明，首先作爲發送端的客戶層在應用層(HTTP協議)發出一個想看某個web頁面的HTTP請求。
接着，爲了傳輸方便，在數據層（TCP協議）把從應用層收到的數據（HTTP請求報文）進行分割，並在各個報文上打上標記序號及端口號後發送給網絡層。
在網絡層（IP協議），增加作爲通信目的地的MAC地址後轉發給鏈路層。這樣一來，發往網絡的通信請求就準備齊全了。
接收端的服務器在鏈路層接收到數據，按序網上曾發送，一直到應用層。當傳輸到應用層，纔算真正接受到由客戶端發送過來的HTTP請求。
發送端在層與層之間傳輸數據時，每經過一層時必定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每經過一層時會把對應的首部消去。
這種把數據信息包裝起來的做法成爲封裝。
簡單的HTTP請求
請求必定由客戶端發出，而服務端回覆響應
HTTP協議規定，請求從客戶端發出，最後服務端響應該請求並返回。換句話說，肯定是先從客戶端開始建立通信的，服務端在沒有接收到請求之前不會發送響應。
實例
下面是從客戶端發送給某個http服務器端的請求報文中的內容。
GET /index.htm HTTP/1.1
Host:hackr.jp起始行開頭的GET表示請求訪問服務器的類型，稱爲方法(method)。隨後的字符串 /index.htm 指明瞭請求訪問的資源對象，也交錯請求URI(request-URI)。 最後的HTTP/1.1 ，即HTTP的版本號，用來提示客戶端使用HTTP的協議功能。
綜合來看，這段請求的內容的意思是：請求訪問某臺HTTP服務器上的/index.htm頁面資源。
請求報文是由請求方法、請求URL、協議版本、可選的請求首部字段和內容實體構成的。
收到請求，服務器會將請求內容的處理結果以響應的形式返回。
HTTP/1.1 200 OK
Date: Tue,10 Jul 2012 06:50:15 GMT
Content-Length:362
Content-Type:text/html
<html>
...在起始行開頭的HTTP/1.1表示服務器對應的HTTP版本。
緊挨着的200 OK表示請求的處理結果的狀態嗎(status code)和原因短語(reason-phrase)。 下一行顯示了創建響應的日期時間，是首部字段(header field)內的一個屬性。
接着以一空行分割，之後的內容稱爲資源實體的主體(entity body)。
響應報文基本上由協議版本、狀態碼、用以解釋狀態嗎的原因短語、可選的響應首部字段以及實體主體構成。稍後我們會對這些內容進行詳細說明。
HTTP是不保存狀態的協議
HTTP是一種不保存狀態，即無狀態(stateless)的協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在HTTP這個級別，協議對於發送過的請求或響應都不做持久化處理。
HTTP/1.1雖然是無狀態協議，單位了實現期望的保持狀態功能，於是引入了Cookie技術。有了Cookie再用HTTP協議通信，就可以管理狀態了。
請求URI定位資源
URI爲完整請求的URI
GET http://example.cn/index.htm HTTP/1.1在首部字段Host中寫明網絡域名或IP地址
GET /index.htm HTTP/1.1
Host:example.cn除此之外，如果不是訪問特定資源而是對服務器本身發起請求，可以用一個*來代替請求URI。下面這個例子是查詢HTTP服務器端支持的HTTP方法種類。
OPTIONS * HTTP/1.1告知服務器意圖的HTTP方法
GET:獲取資源
If-Modified-Since:Thu,12 Jul 2012 07:30:00 GMT 僅返回該時間以後更新過的index.html頁面資源。如果沒有內容更新，則以狀態碼304 Not Modified作爲響應返回。
POST:傳輸實體主體
雖然用GET方法也可以傳輸實體的主體，但一般不用GET方法進行傳輸，而是用POST方法。雖說POST的功能與GET很相似，但POST的主要目的並不是獲取相應的主體內容。
PUT： 傳輸文件
PUT方法用來傳輸文件。就像FTP協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然後保存請求URI指定的位置。
但是，鑑於HTTP/1.1的put方法自身不帶驗證機制，任何人都可以上傳文件，存在安全性問題，因此一般的Web網站不使用該方法。若配合Web應用程序的驗證機制，或架構設計採用REST標準的同類Web網站，就可能會開放使用PUT方法。
HEAD：獲得報文首部
HEAD方法和GET方法一樣，只是不返回報文主體部分。用於確認URI的有效性及資源更新的日期時間等。
DELETE:刪除文件
DELETE方法用來刪除文件，是與PUT相反的方法。DELETE方法按請求URI刪除指定的資源。
但是，HTTP/1.1的DELETE方法本身和PUT方法一樣不帶驗證機制，所以一般的Web網站也不適用DELETE方法。
CONNECT:要求使用隧道協議鏈接代理
CONNECT方法要求在與代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。主要是用SSL（Secure Sockets Layer，安全套接層）和TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密後經過網絡隧道傳輸。
持久連接節省通信量
HTTP協議的初始版本中，每進行一次HTTP通信就要斷開一次TCP鏈接。
持久連接
爲了解決TCP連接的問題，HTTP/1.1和一部分的HTTP/1.0想出了持久鏈接的方法。持久連接的特點是，只要任意一端沒有明確提出斷開鏈接，則保持TCP連接狀態。
持久連接旨在建立1次TCP連接後進行多次請求和響應的交互。
在HTTP/1.1中，所有的連接默認都是持久連接，但在HTTP/1.0內並未標準化。雖然有一部分服務器通過非標準的手段實現了持久連接，但服務端不一定能夠支持持久連接。毫無疑問，除了服務器端，客戶端也要支持持久連接。
管線化
持久連接使得多數請求以管線化的方式發送成爲可能。從前發出請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。
這樣就能做到同時並行發送多個請求。
使用Cookie的狀態管理
HTPP是無狀態協議，它不對之前發生過的請求和響應的狀態進行管理。
保留狀態協議這個特徵的同事又要解決類似的矛盾問題，於是引入了Cookie技術。Cookie技術通過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。
IP、TCP、NDS和URI
負責傳輸的IP協議
按層次分，IP（Internet Protocol）網際協議位於網絡層。所有使用網絡的系統都會用到IP協議。TCP/IP協議族中的IP指的就是網際協議，協議名稱中佔據了一半位置，其重要性可見一斑。
IP和IP地址不同，”IP”其實是一種協議的名稱。
IP協議的作用是把各種數據包傳送給對方。而要保證確實傳送到對方那裏，則需要滿足各類條件。其中兩個重要的條件是IP地址和MAC地址（Media Access Control Address)
IP地址指明瞭節點被分配到的地址，MAC地址是指網卡所屬的固定地址。IP地址可以和MAC地址進行配對。IP地址可變換，但MAC地址基本上不會更改。
使用ARP協議憑藉着MAC地址進行通信。
IP間的通信依賴MAC地址。在網絡上，通信的雙方在同一局域網（LAN）內的情況是很少的，通常是經過多臺計算機和網絡設備中轉才能連接到對方。而在進行中轉時，會利用下一站中轉設備的MAC地址來搜索下一個中轉目標。這時，會採用ARP協議（Address Resolution Protocol）。ARP是一種用於解析地址的協議，根據通信方的IP地址就可以反查出對應的MAC地址。
沒有人能在全面掌握互聯網中的傳出狀況。
在到達通信目標前的中轉過程中，哪些計算機和路由器等網絡設備只能獲悉很粗略的傳輸路線。
這種機制稱爲路由選擇，有點像快遞公司的送貨過程。
確保可靠性的TCP協議
按層次分，TCP位於傳輸層，提供可靠的字節流服務。
所謂的字節流服務（Byte Stream Service）是指，爲了方便傳輸，將大塊數據分割成以報文段爲單位的數據包進行管理。而可靠地傳輸服務是指，能夠把數據準確可靠的傳給對方。一言以蔽之，TCP協議爲了更容易傳送大數據才把數據分割，而且TCP協議能夠確認數據最終是否送達對方。
三次握手
TCP協議把數據包送出去之後，一定會向對方確認是否成功送達。
握手過程中使用了TCP的標誌————SYN(synchronize)和ACK(acknowledgement).
發送端首先發送一個帶SYN標誌的數據包給對方。接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後，發送端再回傳一個帶ACK標誌的數據包，代表“握手”結束。
負責域名解析的DNS服務
DNS（Domain Name System)服務是和HTTP協議一樣位於應用層的協議。
它提供域名到IP地址之間的解析服務。
計算機既可以被賦予IP地址，也可以被賦予主機名和域名。
用戶通常使用主機名或域名來訪問對方的計算機，而不是直接通過IP地址訪問。因爲與IP地址的一組純數字相比，用字母配合數字的表示形式來指定計算機名更符合人類的記憶習慣。
但是要讓計算機去理解名稱，相對而言就變得困難了。因爲傑斯算計更擅長處理一長串數字。
爲了解決上述的問題，DNS服務應運而生。DNS協議提供通過域名查找IP地址，或逆向從IP地址反查域名的服務。
各種協議與HTTP協議的關係
客戶端向DNS服務器發送URL，返回IP地址。
HTTP協議的職責： 生成針對目標WEB服務器的HTTP請求報文。
TCP協議的職責：爲了方便通信，將HTTP請求報文分割成報文段，按序號分爲多少個報文段。把每個報文段可靠地傳遞給對方。
IP協議的職責：搜索對方的地址，一邊中轉一邊傳送。
TCP協議的職責（服務器）： 從對方那裏接收到的報文段，重組到達的報文段。按序號以原來的順序重組請求報文。
HTTP協議的職責（服務器）：對WEB服務器請求的內容的處理
請求處理的結果利用TCP/IP通信協議向用戶進行回傳。
URL和URI
URI
URI是Uniform Resource Identifier的縮寫。RFC2396分別對這三個單詞進行了如下定義。
Uniform
規定統一的格式可方便處理多種不同類型的資源，而不用根據上下文環境來識別資源指定的訪問方式。另外，加入新增的協議方案(如http:或ftp:)也更容易。
Resource
資源的定義是“可標識的任何東西”。除了文檔文件、圖像或服務（例如當天的天氣預報）等能夠區別於其他類型的，全部都可作爲資源。另外，資源不僅可以是單一的，也可以是多數的集合體。
Identifier
表示可表示的對象。也成爲標識符。
綜上所述，URI就是由某個協議方案表示的資源的定位標識符。協議方案是指訪問資源使用的協議類型名稱。
採用HTTP協議時，協議方案就是HTTP。除此之外還有FTP、mailto、telnet、file等。標準的URI協議方案有30種左右。
Uri用字符串標識某一互聯網資源，而URL標識資源的地點（互聯網上所處的位置）。可見URL是URI的子集。
URI格式
表示指定的URI，要是用涵蓋全部必要信息的絕對URI、絕對URL以及相對URL。