1. 在瀏覽器中輸入url地址 ->> 顯示主頁的過程,整個(gè)過程會(huì)使用哪些協(xié)議
總體來說分為以下幾個(gè)過程:
- DNS解析
- TCP連接
- 發(fā)送HTTP請求
- 服務(wù)器處理請求并返回HTTP報(bào)文
- 瀏覽器解析渲染頁面
- 連接結(jié)束
在瀏覽器中輸入網(wǎng)址之后執(zhí)行會(huì)發(fā)生什么？
- DNS解析，找到對應(yīng)ip地址
- 客戶端發(fā)起http/https請求,然后交給傳輸層
- 傳輸層將請求分成報(bào)文段，添加目標(biāo)源和端口，并隨機(jī)用一個(gè)本地接口封裝進(jìn)報(bào)頭，然后交給網(wǎng)絡(luò)層。
- 網(wǎng)絡(luò)層加上雙方的ip地址信息，并負(fù)責(zé)路由分發(fā)。
- 鏈路層中，包通過鏈路層發(fā)送到路由器，通過鄰居協(xié)議查找給定IP地址的MAC地址，然后發(fā)送ARP請求查找目的地址，如果得到回應(yīng)后就可以使用ARP的請求應(yīng)答交換的IP數(shù)據(jù)包進(jìn)行傳輸了，然后發(fā)送IP數(shù)據(jù)包到達(dá)服務(wù)器的地址。
各種協(xié)議與HTTP協(xié)議之間的關(guān)系一般面試官會(huì)通過這樣的問題來考察你對計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)體系的理解。
圖片來源：《圖解HTTP》
2.TCP/IP協(xié)議層
1.1 應(yīng)用層
應(yīng)用層(application-layer）的任務(wù)是通過應(yīng)用進(jìn)程間的交互來完成特定網(wǎng)絡(luò)應(yīng)用。應(yīng)用層協(xié)議定義的是應(yīng)用進(jìn)程（進(jìn)程：主機(jī)中正在運(yùn)行的程序）間的通信和交互的規(guī)則。對于不同的網(wǎng)絡(luò)應(yīng)用需要不同的應(yīng)用層協(xié)議。在互聯(lián)網(wǎng)中應(yīng)用層協(xié)議很多，如域名系統(tǒng)DNS，支持萬維網(wǎng)應(yīng)用的 HTTP協(xié)議，支持電子郵件的 SMTP協(xié)議等等。我們把應(yīng)用層交互的數(shù)據(jù)單元稱為報(bào)文。
域名系統(tǒng)
域名系統(tǒng)(Domain Name System縮寫 DNS，Domain Name被譯為域名)是因特網(wǎng)的一項(xiàng)核心服務(wù)，它作為可以將域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫，能夠使人更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機(jī)器直接讀取的IP數(shù)串。（百度百科）例如：一個(gè)公司的 Web 網(wǎng)站可看作是它在網(wǎng)上的門戶，而域名就相當(dāng)于其門牌地址，通常域名都使用該公司的名稱或簡稱。例如上面提到的微軟公司的域名，類似的還有：IBM 公司的域名是 www.ibm.com、Oracle 公司的域名是 www.oracle.com、Cisco公司的域名是 www.cisco.com 等。
HTTP協(xié)議
超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的 WWW（萬維網(wǎng)） 文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì) HTTP 最初的目的是為了提供一種發(fā)布和接收 HTML 頁面的方法。（百度百科）1.2 運(yùn)輸層
運(yùn)輸層(transport layer)的主要任務(wù)就是負(fù)責(zé)向兩臺(tái)主機(jī)進(jìn)程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)。應(yīng)用進(jìn)程利用該服務(wù)傳送應(yīng)用層報(bào)文?！巴ㄓ玫摹笔侵覆⒉会槍δ骋粋€(gè)特定的網(wǎng)絡(luò)應(yīng)用，而是多種應(yīng)用可以使用同一個(gè)運(yùn)輸層服務(wù)。由于一臺(tái)主機(jī)可同時(shí)運(yùn)行多個(gè)線程，因此運(yùn)輸層有復(fù)用和分用的功能。所謂復(fù)用就是指多個(gè)應(yīng)用層進(jìn)程可同時(shí)使用下面運(yùn)輸層的服務(wù)，分用和復(fù)用相反，是運(yùn)輸層把收到的信息分別交付上面應(yīng)用層中的相應(yīng)進(jìn)程。
運(yùn)輸層
主要使用以下兩種協(xié)議:
- 傳輸控制協(xié)議 TCP（Transmission Control Protocol）--提供面向連接的，可靠的數(shù)據(jù)傳輸服務(wù)。
- 用戶數(shù)據(jù)協(xié)議 UDP（User Datagram Protocol）--提供無連接的，盡最大努力的數(shù)據(jù)傳輸服務(wù)（不保證數(shù)據(jù)傳輸?shù)目煽啃裕?/li>
1.3 網(wǎng)絡(luò)層
在 計(jì)算機(jī)網(wǎng)絡(luò)中進(jìn)行通信的兩個(gè)計(jì)算機(jī)之間可能會(huì)經(jīng)過很多個(gè)數(shù)據(jù)鏈路，也可能還要經(jīng)過很多通信子網(wǎng)。網(wǎng)絡(luò)層的任務(wù)就是選擇合適的網(wǎng)間路由和交換結(jié)點(diǎn)， 確保數(shù)據(jù)及時(shí)傳送。 在發(fā)送數(shù)據(jù)時(shí)，網(wǎng)絡(luò)層把運(yùn)輸層產(chǎn)生的報(bào)文段或用戶數(shù)據(jù)報(bào)封裝成分組和包進(jìn)行傳送。在 TCP/IP 體系結(jié)構(gòu)中，由于網(wǎng)絡(luò)層使用 IP 協(xié)議，因此分組也叫 IP 數(shù)據(jù)報(bào) ，簡稱 數(shù)據(jù)報(bào)。
這里要注意：不要把運(yùn)輸層的“用戶數(shù)據(jù)報(bào) UDP ”和網(wǎng)絡(luò)層的“ IP 數(shù)據(jù)報(bào)”弄混。另外，無論是哪一層的數(shù)據(jù)單元，都可籠統(tǒng)地用“分組”來表示。
這里強(qiáng)調(diào)指出，網(wǎng)絡(luò)層中的“網(wǎng)絡(luò)”二字已經(jīng)不是我們通常談到的具體網(wǎng)絡(luò)，而是指計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)模型中第三層的名稱.
互聯(lián)網(wǎng)是由大量的異構(gòu)（heterogeneous）網(wǎng)絡(luò)通過路由器（router）相互連接起來的?；ヂ?lián)網(wǎng)使用的網(wǎng)絡(luò)層協(xié)議是無連接的網(wǎng)際協(xié)議（Intert Protocol）和許多路由選擇協(xié)議，因此互聯(lián)網(wǎng)的網(wǎng)絡(luò)層也叫做網(wǎng)際層或IP層。
1.4 數(shù)據(jù)鏈路層
數(shù)據(jù)鏈路層(data link layer)通常簡稱為鏈路層。兩臺(tái)主機(jī)之間的數(shù)據(jù)傳輸，總是在一段一段的鏈路上傳送的，這就需要使用專門的鏈路層的協(xié)議。 在兩個(gè)相鄰節(jié)點(diǎn)之間傳送數(shù)據(jù)時(shí)，數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來的 IP 數(shù)據(jù)報(bào)組裝程幀，在兩個(gè)相鄰節(jié)點(diǎn)間的鏈路上傳送幀。每一幀包括數(shù)據(jù)和必要的控制信息（如同步信息，地址信息，差錯(cuò)控制等）。
在接收數(shù)據(jù)時(shí)，控制信息使接收端能夠知道一個(gè)幀從哪個(gè)比特開始和到哪個(gè)比特結(jié)束。這樣，數(shù)據(jù)鏈路層在收到一個(gè)幀后，就可從中提出數(shù)據(jù)部分，上交給網(wǎng)絡(luò)層。 控制信息還使接收端能夠檢測到所收到的幀中有誤差錯(cuò)。如果發(fā)現(xiàn)差錯(cuò)，數(shù)據(jù)鏈路層就簡單地丟棄這個(gè)出了差錯(cuò)的幀，以避免繼續(xù)在網(wǎng)絡(luò)中傳送下去白白浪費(fèi)網(wǎng)絡(luò)資源。如果需要改正數(shù)據(jù)在鏈路層傳輸時(shí)出現(xiàn)差錯(cuò)（這就是說，數(shù)據(jù)鏈路層不僅要檢錯(cuò)，而且還要糾錯(cuò)），那么就要采用可靠性傳輸協(xié)議來糾正出現(xiàn)的差錯(cuò)。這種方法會(huì)使鏈路層的協(xié)議復(fù)雜些。
1.5 物理層
在物理層上所傳送的數(shù)據(jù)單位是比特。 物理層(physical layer)的作用是實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送，盡可能屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異。 使其上面的數(shù)據(jù)鏈路層不必考慮網(wǎng)絡(luò)的具體傳輸介質(zhì)是什么。“透明傳送比特流”表示經(jīng)實(shí)際電路傳送后的比特流沒有發(fā)生變化，對傳送的比特流來說，這個(gè)電路好像是看不見的。
在互聯(lián)網(wǎng)使用的各種協(xié)中最重要和最著名的就是 TCP/IP 兩個(gè)協(xié)議?，F(xiàn)在人們經(jīng)常提到的TCP/IP并不一定單指TCP和IP這兩個(gè)具體的協(xié)議，而往往表示互聯(lián)網(wǎng)所使用的整個(gè)TCP/IP協(xié)議族。
1). 物理層
參考模型的最低層，也是OSI模型的第一層，實(shí)現(xiàn)了相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送，并盡可能地屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異，使其上層(數(shù)據(jù)鏈路層)不必關(guān)心網(wǎng)絡(luò)的具體傳輸介質(zhì)。
2). 數(shù)據(jù)鏈路層（data link layer）
接收來自物理層的位流形式的數(shù)據(jù)，并封裝成幀，傳送到上一層；同樣，也將來自上層的數(shù)據(jù)幀，拆裝為位流形式的數(shù)據(jù)轉(zhuǎn)發(fā)到物理層。這一層在物理層提供的比特流的基礎(chǔ)上，通過差錯(cuò)控制、流量控制方法，使有差錯(cuò)的物理線路變?yōu)闊o差錯(cuò)的數(shù)據(jù)鏈路，即提供可靠的通過物理介質(zhì)傳輸數(shù)據(jù)的方法。
3). 網(wǎng)絡(luò)層
將網(wǎng)絡(luò)地址翻譯成對應(yīng)的物理地址，并通過路由選擇算法為分組通過通信子網(wǎng)選擇最適當(dāng)?shù)穆窂健?/p>
4). 傳輸層（transport layer）
在源端與目的端之間提供可靠的透明數(shù)據(jù)傳輸，使上層服務(wù)用戶不必關(guān)系通信子網(wǎng)的實(shí)現(xiàn)細(xì)節(jié)。在協(xié)議棧中，傳輸層位于網(wǎng)絡(luò)層之上，傳輸層協(xié)議為不同主機(jī)上運(yùn)行的進(jìn)程提供邏輯通信，而網(wǎng)絡(luò)層協(xié)議為不同主機(jī)提供邏輯通信，如下圖所示。
實(shí)際上，網(wǎng)絡(luò)層可以看作是傳輸層的一部分，其為傳輸層提供服務(wù)。但對于終端系統(tǒng)而言，網(wǎng)絡(luò)層對它們而言是透明的，它們知道傳輸層的存在，也就是說，在邏輯上它們認(rèn)為是傳輸層為它們提供了端對端的通信，這也是分層思想的妙處。
5). 會(huì)話層（Session Layer）
會(huì)話層是OSI模型的第五層，是用戶應(yīng)用程序和網(wǎng)絡(luò)之間的接口，負(fù)責(zé)在網(wǎng)絡(luò)中的兩節(jié)點(diǎn)之間建立、維持和終止通信。
6). 表示層（Presentation Layer）：數(shù)據(jù)的編碼，壓縮和解壓縮，數(shù)據(jù)的加密和解
表示層是OSI模型的第六層，它對來自應(yīng)用層的命令和數(shù)據(jù)進(jìn)行解釋，以確保一個(gè)系統(tǒng)的應(yīng)用層所發(fā)送的信息可以被另一個(gè)系統(tǒng)的應(yīng)用層讀取。
7). 應(yīng)用層（Application layer）：為用戶的應(yīng)用進(jìn)程提供網(wǎng)絡(luò)通信服務(wù)
3. TCP對應(yīng)的應(yīng)用層協(xié)議
FTP：定義了文件傳輸協(xié)議，使用21端口。常說某某計(jì)算機(jī)開了FTP服務(wù)便是啟動(dòng)了文件傳輸服務(wù)。下載文件，上傳主頁，都要用到FTP服務(wù)。
Telnet：它是一種用于遠(yuǎn)程登陸的端口，用戶可以以自己的身份遠(yuǎn)程連接到計(jì)算機(jī)上，通過這種端口可以提供一種基于DOS模式下的通信服務(wù)。如以前的BBS是-純字符界面的，支持BBS的服務(wù)器將23端口打開，對外提供服務(wù)。
SMTP：定義了簡單郵件傳送協(xié)議，現(xiàn)在很多郵件服務(wù)器都用的是這個(gè)協(xié)議，用于發(fā)送郵件。如常見的免費(fèi)郵件服務(wù)中用的就是這個(gè)郵件服務(wù)端口，所以在電子郵件設(shè)置-中常看到有這么SMTP端口設(shè)置這個(gè)欄，服務(wù)器開放的是25號端口。
POP3：它是和SMTP對應(yīng)，POP3用于接收郵件。通常情況下，POP3協(xié)議所用的是110端口。也是說，只要你有相應(yīng)的使用POP3協(xié)議的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陸進(jìn)郵箱界面，直接用郵件程序就可以收到郵件（如是163郵箱就沒有必要先進(jìn)入網(wǎng)易網(wǎng)站，再進(jìn)入自己的郵-箱來收信）。
HTTP：從Web服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。
4. UDP對應(yīng)的應(yīng)用層協(xié)議
DNS：用于域名解析服務(wù)，將域名地址轉(zhuǎn)換為IP地址。DNS用的是53號端口。
SNMP：簡單網(wǎng)絡(luò)管理協(xié)議，使用161號端口，是用來管理網(wǎng)絡(luò)設(shè)備的。由于網(wǎng)絡(luò)設(shè)備很多，無連接的服務(wù)就體現(xiàn)出其優(yōu)勢。
TFTP(Trival File Transfer Protocal)：簡單文件傳輸協(xié)議，該協(xié)議在熟知端口69上使用UDP服務(wù)。
5. TCP/UDP
TCP/UDP都是是傳輸層協(xié)議，但是兩者具有不同的特性，同時(shí)也具有不同的應(yīng)用場景
什么時(shí)候應(yīng)該使用TCP
當(dāng)對網(wǎng)絡(luò)通訊質(zhì)量有要求的時(shí)候，比如：整個(gè)數(shù)據(jù)要準(zhǔn)確無誤的傳遞給對方，這往往用于一些要求可靠的應(yīng)用，比如HTTP、HTTPS、FTP等傳輸文件的協(xié)議，POP、SMTP等郵件傳輸?shù)膮f(xié)議。
什么時(shí)候應(yīng)該使用UDP
當(dāng)對網(wǎng)絡(luò)通訊質(zhì)量要求不高的時(shí)候，要求網(wǎng)絡(luò)通訊速度能盡量的快，這時(shí)就可以使用UDP。
8..三次握手，四次揮手
9. 為什么要三次握手
三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是數(shù)據(jù)的發(fā)送與接收，而三次握手最主要的目的就是雙方確認(rèn)自己與對方的發(fā)送與接收是正常的。
第一次握手：Client 什么都不能確認(rèn)；Server 確認(rèn)了對方發(fā)送正常，自己接收正常。
第二次握手：Client 確認(rèn)了：自己發(fā)送、接收正常，對方發(fā)送、接收正常；Server 確認(rèn)了：自己接收正常，對方發(fā)送正常
第三次握手：Client 確認(rèn)了：自己發(fā)送、接收正常，對方發(fā)送、接收正常；Server 確認(rèn)了：自己發(fā)送、接收正常，對方發(fā)送接收正常
所以三次握手就能確認(rèn)雙發(fā)收發(fā)功能都正常，缺一不可。
10.為什么要四次揮手
任何一方都可以在數(shù)據(jù)傳送結(jié)束后發(fā)出連接釋放的通知，待對方確認(rèn)后進(jìn)入半關(guān)閉狀態(tài)。當(dāng)另一方也沒有數(shù)據(jù)再發(fā)送的時(shí)候，則發(fā)出連接釋放通知，對方確認(rèn)后就完全關(guān)閉了TCP連接。
舉個(gè)例子：A 和 B 打電話，通話即將結(jié)束后，A 說“我沒啥要說的了”，B回答“我知道了”，但是 B 可能還會(huì)有要說的話，A 不能要求 B 跟著自己的節(jié)奏結(jié)束通話，于是 B 可能又巴拉巴拉說了一通，最后 B 說“我說完了”，A 回答“知道了”，這樣通話才算結(jié)束。
11.對于可靠性，TCP通過以下方式進(jìn)行保證：
- 數(shù)據(jù)包校驗(yàn)：目的是檢測數(shù)據(jù)在傳輸過程中的任何變化，若校驗(yàn)出包有錯(cuò)，則丟棄報(bào)文段并且不給出響應(yīng)，這時(shí)TCP發(fā)送數(shù)據(jù)端超時(shí)后會(huì)重發(fā)數(shù)據(jù)；
- 對失序數(shù)據(jù)包重排序：既然TCP報(bào)文段作為IP數(shù)據(jù)報(bào)來傳輸，而IP數(shù)據(jù)報(bào)的到達(dá)可能會(huì)失序，因此TCP報(bào)文段的到達(dá)也可能會(huì)失序。TCP將對失序數(shù)據(jù)進(jìn)行重新排序，然后才交給應(yīng)用層；
- 丟棄重復(fù)數(shù)據(jù)：對于重復(fù)數(shù)據(jù)，能夠丟棄重復(fù)數(shù)據(jù)；
- 應(yīng)答機(jī)制：當(dāng)TCP收到發(fā)自TCP連接另一端的數(shù)據(jù)，它將發(fā)送一個(gè)確認(rèn)。這個(gè)確認(rèn)不是立即發(fā)送，通常將推遲幾分之一秒；
- 超時(shí)重發(fā)：當(dāng)TCP發(fā)出一個(gè)段后，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段；
- 流量控制：TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出，這就是流量控制。TCP使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。
12.超時(shí)重發(fā)
當(dāng)發(fā)送者向接收者發(fā)包后，如果過了一段時(shí)間(超時(shí)時(shí)間)依然沒有收到消息，就當(dāng)做本次包丟失，需要重新補(bǔ)發(fā)。
并且如果一次性發(fā)了三個(gè)包，只要最后一個(gè)包確認(rèn)收到之后就默認(rèn)前面兩個(gè)也收到了。
13. 滑動(dòng)窗口
假設(shè)一次性發(fā)送包的大小為3，那么每次可以發(fā)3個(gè)包，而且可以邊發(fā)邊接收，這樣就會(huì)增強(qiáng)效率。這里的 3 就是滑動(dòng)窗口的大小，這樣的發(fā)送方式也叫滑動(dòng)窗口協(xié)議。
14.默認(rèn)端口號
1.HTTP協(xié)議代理服務(wù)器常用端口號：80/8080/3128/8081/9098
2.SOCKS代理協(xié)議服務(wù)器常用端口號：1080
3.FTP（文件傳輸）協(xié)議代理服務(wù)器常用端口號：21
4.Telnet（遠(yuǎn)程登錄）協(xié)議代理服務(wù)器常用端口號：23
HTTP服務(wù)器，默認(rèn)端口號為80/tcp（木馬Executor開放此端口）
HTTPS（securely transferring web pages）服務(wù)器，默認(rèn)端口號為443/tcp 443/udp
IP地址與MAC地址的區(qū)別
IP地址是指互聯(lián)網(wǎng)協(xié)議地址（Internet Protocol Address）IP Address的縮寫。IP地址是IP協(xié)議提供的一種統(tǒng)一的地址格式，它為互聯(lián)網(wǎng)上的每一個(gè)網(wǎng)絡(luò)和每一臺(tái)主機(jī)分配一個(gè)邏輯地址，以此來屏蔽物理地址的差異。
MAC 地址又稱為物理地址、硬件地址，用來定義網(wǎng)絡(luò)設(shè)備的位置。網(wǎng)卡的物理地址通常是由網(wǎng)卡生產(chǎn)廠家寫入網(wǎng)卡的，具有全球唯一性。MAC地址用于在網(wǎng)絡(luò)中唯一標(biāo)示一個(gè)網(wǎng)卡，一臺(tái)電腦會(huì)有一或多個(gè)網(wǎng)卡，每個(gè)網(wǎng)卡都需要有一個(gè)唯一的MAC地址。
15.HTTP請求/響應(yīng)報(bào)文結(jié)構(gòu)
請求
HTTP請求報(bào)文
一個(gè)HTTP請求報(bào)文由四個(gè)部分組成：請求行、請求頭部、空行、請求數(shù)據(jù)。
1.請求行
請求行由請求方法字段、URL字段和HTTP協(xié)議版本字段3個(gè)字段組成，它們用空格分隔。比如 GET /data/info.html HTTP/1.1
方法字段就是HTTP使用的請求方法，比如常見的GET/POST
其中HTTP協(xié)議版本有兩種：HTTP1.0/HTTP1.1 可以這樣區(qū)別：
HTTP1.0對于每個(gè)連接都只能傳送一個(gè)請求和響應(yīng)，請求就會(huì)關(guān)閉，HTTP1.0沒有Host字段;而HTTP1.1在同一個(gè)連接中可以傳送多個(gè)請求和響應(yīng)，多個(gè)請求可以重疊和同時(shí)進(jìn)行，HTTP1.1必須有Host字段。
2.請求頭部
HTTP客戶程序(例如瀏覽器)，向服務(wù)器發(fā)送請求的時(shí)候必須指明請求類型(一般是GET或者 POST)。如有必要，客戶程序還可以選擇發(fā)送其他的請求頭。大多數(shù)請求頭并不是必需的，但Content-Length除外。對于POST請求來說 Content-Length必須出現(xiàn)。
常見的請求頭字段含義：
Accept： 瀏覽器可接受的MIME類型。
Accept-Charset：瀏覽器可接受的字符集。
Accept-Encoding：瀏覽器能夠進(jìn)行解碼的數(shù)據(jù)編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經(jīng)gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時(shí)間。
Accept-Language：瀏覽器所希望的語言種類，當(dāng)服務(wù)器能夠提供一種以上的語言版本時(shí)要用到。
Authorization：授權(quán)信息，通常出現(xiàn)在對服務(wù)器發(fā)送的WWW-Authenticate頭的應(yīng)答中。
Content-Length：表示請求消息正文的長度。
Host： 客戶機(jī)通過這個(gè)頭告訴服務(wù)器，想訪問的主機(jī)名。Host頭域指定請求資源的Intenet主機(jī)和端口號，必須表示請求url的原始服務(wù)器或網(wǎng)關(guān)的位置。HTTP/1.1請求必須包含主機(jī)頭域，否則系統(tǒng)會(huì)以400狀態(tài)碼返回。
If-Modified-Since：客戶機(jī)通過這個(gè)頭告訴服務(wù)器，資源的緩存時(shí)間。只有當(dāng)所請求的內(nèi)容在指定的時(shí)間后又經(jīng)過修改才返回它，否則返回304“Not Modified”應(yīng)答。
Referer：客戶機(jī)通過這個(gè)頭告訴服務(wù)器，它是從哪個(gè)資源來訪問服務(wù)器的(防盜鏈)。包含一個(gè)URL，用戶從該URL代表的頁面出發(fā)訪問當(dāng)前請求的頁面。
User-Agent：User-Agent頭域的內(nèi)容包含發(fā)出請求的用戶信息。瀏覽器類型，如果Servlet返回的內(nèi)容與瀏覽器類型有關(guān)則該值非常有用。
Cookie：客戶機(jī)通過這個(gè)頭可以向服務(wù)器帶數(shù)據(jù)，這是最重要的請求頭信息之一。
Pragma：指定“no-cache”值表示服務(wù)器必須返回一個(gè)刷新后的文檔，即使它是代理服務(wù)器而且已經(jīng)有了頁面的本地拷貝。
From：請求發(fā)送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會(huì)用到它。
Connection：處理完這次請求后是否斷開連接還是繼續(xù)保持連接。如果Servlet看到這里的值為“Keep- Alive”，或者看到請求使用的是HTTP 1.1(HTTP 1.1默認(rèn)進(jìn)行持久連接)，它就可以利用持久連接的優(yōu)點(diǎn)，當(dāng)頁面包含多個(gè)元素時(shí)(例如Applet，圖片)，顯著地減少下載所需要的時(shí)間。要實(shí)現(xiàn)這一點(diǎn)，Servlet需要在應(yīng)答中發(fā)送一個(gè)Content-Length頭，最簡單的實(shí)現(xiàn)方法是：先把內(nèi)容寫入 ByteArrayOutputStream，然后在正式寫出內(nèi)容之前計(jì)算它的大小。
Range：Range頭域可以請求實(shí)體的一個(gè)或者多個(gè)子范圍。例如，
表示頭500個(gè)字節(jié)：bytes=0-499
表示第二個(gè)500字節(jié)：bytes=500-999
表示最后500個(gè)字節(jié)：bytes=-500
表示500字節(jié)以后的范圍：bytes=500-
第一個(gè)和最后一個(gè)字節(jié)：bytes=0-0,-1
同時(shí)指定幾個(gè)范圍：bytes=500-600,601-999
但是服務(wù)器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應(yīng)會(huì)以狀態(tài)碼206(PartialContent)返回而不是以200 (OK)。
UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發(fā)送的非標(biāo)準(zhǔn)的請求頭，表示屏幕大小、顏色深度、操作系統(tǒng)和CPU類型。
3.空行
它的作用是通過一個(gè)空行，告訴服務(wù)器請求頭部到此為止。
4.請求數(shù)據(jù)
若方法字段是GET，則此項(xiàng)為空，沒有數(shù)據(jù)
若方法字段是POST,則通常來說此處放置的就是要提交的數(shù)據(jù)
比如要使用POST方法提交一個(gè)表單，其中有user字段中數(shù)據(jù)為“admin”, password字段為123456，那么這里的請求數(shù)據(jù)就是 user=admin&password=123456，使用&來連接各個(gè)字段。
響應(yīng)
上面是POST方法，它的請求行URL段中一般是沒有參數(shù)的，參數(shù)放在了報(bào)文體中。而GET方法的參數(shù)直接置于請求行URL中，報(bào)文體則為空。
HTTP響應(yīng)報(bào)文
同樣的，HTTP響應(yīng)報(bào)文也由三部分組成：響應(yīng)行、響應(yīng)頭、響應(yīng)體
1.響應(yīng)行
響應(yīng)行一般由協(xié)議版本、狀態(tài)碼及其描述組成 比如 HTTP/1.1 200 OK
其中協(xié)議版本HTTP/1.1或者HTTP/1.0，200就是它的狀態(tài)碼，OK則為它的描述。
//常見狀態(tài)碼：
100~199：表示成功接收請求，要求客戶端繼續(xù)提交下一次請求才能完成整個(gè)處理過程。
200~299：表示成功接收請求并已完成整個(gè)處理過程。常用200
300~399：為完成請求，客戶需進(jìn)一步細(xì)化請求。例如：請求的資源已經(jīng)移動(dòng)一個(gè)新地址、常用302(意味著你請求我，我讓你去找別人),307和304(我不給你這個(gè)資源，自己拿緩存)
400~499：客戶端的請求有錯(cuò)誤，常用404(意味著你請求的資源在web服務(wù)器中沒有)403(服務(wù)器拒絕訪問，權(quán)限不夠)
500~599：服務(wù)器端出現(xiàn)錯(cuò)誤，常用500
更詳細(xì)的狀態(tài)碼信息
2.響應(yīng)頭
響應(yīng)頭用于描述服務(wù)器的基本信息，以及數(shù)據(jù)的描述，服務(wù)器通過這些數(shù)據(jù)的描述信息，可以通知客戶端如何處理等一會(huì)兒它回送的數(shù)據(jù)。
設(shè)置HTTP響應(yīng)頭往往和狀態(tài)碼結(jié)合起來。例如，有好幾個(gè)表示“文檔位置已經(jīng)改變”的狀態(tài)代碼都伴隨著一個(gè)Location頭，而401(Unauthorized)狀態(tài)代碼則必須伴隨一個(gè)WWW-Authenticate頭。然而，即使在沒有設(shè)置特殊含義的狀態(tài)代碼時(shí)，指定應(yīng)答頭也是很有用的。應(yīng)答頭可以用來完成：設(shè)置Cookie，指定修改日期，指示瀏覽器按照指定的間隔刷新頁面，聲明文檔的長度以便利用持久HTTP連接，……等等許多其他任務(wù)。
常見的響應(yīng)頭字段含義：
Allow：服務(wù)器支持哪些請求方法(如GET、POST等)。
Content-Encoding：文檔的編碼(Encode)方法。只有在解碼之后才可以得到Content-Type頭指定的內(nèi)容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時(shí)間。Java的GZIPOutputStream可以很方便地進(jìn)行g(shù)zip壓縮，但只有Unix上的Netscape和Windows上的IE4、IE5才支持它。因此，Servlet應(yīng)該通過查看Accept-Encoding頭(即request.getHeader(“Accept- Encoding”))檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經(jīng)gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。
Content-Length：表示內(nèi)容長度。只有當(dāng)瀏覽器使用持久HTTP連接時(shí)才需要這個(gè)數(shù)據(jù)。如果你想要利用持久連接的優(yōu)勢，可以把輸出文檔寫入 ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過byteArrayStream.writeTo(response.getOutputStream()發(fā)送內(nèi)容。
Content- Type：表示后面的文檔屬于什么MIME類型。Servlet默認(rèn)為text/plain，但通常需要顯式地指定為text/html。由于經(jīng)常要設(shè)置 Content-Type，因此HttpServletResponse提供了一個(gè)專用的方法setContentType。
Date：當(dāng)前的GMT時(shí)間，例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時(shí)間表示世界標(biāo)準(zhǔn)時(shí)，換算成本地時(shí)間，需要知道用戶所在的時(shí)區(qū)。你可以用setDateHeader來設(shè)置這個(gè)頭以避免轉(zhuǎn)換時(shí)間格式的麻煩。
Expires：告訴瀏覽器把回送的資源緩存多長時(shí)間，-1或0則是不緩存。
Last-Modified：文檔的最后改動(dòng)時(shí)間?？蛻艨梢酝ㄟ^If-Modified-Since請求頭提供一個(gè)日期，該請求將被視為一個(gè)條件GET，只有改動(dòng)時(shí)間遲于指定時(shí)間的文檔才會(huì)返回，否則返回一個(gè)304(Not Modified)狀態(tài)。Last-Modified也可用setDateHeader方法來設(shè)置。
Location：這個(gè)頭配合302狀態(tài)碼使用，用于重定向接收者到一個(gè)新URI地址。表示客戶應(yīng)當(dāng)?shù)侥睦锶ヌ崛∥臋n。Location通常不是直接設(shè)置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時(shí)設(shè)置狀態(tài)代碼為302。
Refresh：告訴瀏覽器隔多久刷新一次，以秒計(jì)。
Server：服務(wù)器通過這個(gè)頭告訴瀏覽器服務(wù)器的類型。Server響應(yīng)頭包含處理請求的原始服務(wù)器的軟件信息。此域能包含多個(gè)產(chǎn)品標(biāo)識(shí)和注釋，產(chǎn)品標(biāo)識(shí)一般按照重要性排序。Servlet一般不設(shè)置這個(gè)值，而是由Web服務(wù)器自己設(shè)置。
Set-Cookie：設(shè)置和頁面關(guān)聯(lián)的Cookie。Servlet不應(yīng)使用response.setHeader(“Set-Cookie”, …)，而是應(yīng)使用HttpServletResponse提供的專用方法addCookie。
Transfer-Encoding：告訴瀏覽器數(shù)據(jù)的傳送格式。
WWW-Authenticate：客戶應(yīng)該在Authorization頭中提供什么類型的授權(quán)信息?在包含401(Unauthorized)狀態(tài)行的應(yīng)答中這個(gè)頭是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=\”executives\”“)。注意Servlet一般不進(jìn)行這方面的處理，而是讓W(xué)eb服務(wù)器的專門機(jī)制來控制受密碼保護(hù)頁面的訪問。
注：設(shè)置應(yīng)答頭最常用的方法是HttpServletResponse的setHeader，該方法有兩個(gè)參數(shù)，分別表示應(yīng)答頭的名字和值。和設(shè)置狀態(tài)代碼相似，設(shè)置應(yīng)答頭應(yīng)該在發(fā)送任何文檔內(nèi)容之前進(jìn)行。
setDateHeader方法和setIntHeadr方法專門用來設(shè)置包含日期和整數(shù)值的應(yīng)答頭，前者避免了把Java時(shí)間轉(zhuǎn)換為GMT時(shí)間字符串的麻煩，后者則避免了把整數(shù)轉(zhuǎn)換為字符串的麻煩。
HttpServletResponse還提供了許多設(shè)置
setContentType：設(shè)置Content-Type頭。大多數(shù)Servlet都要用到這個(gè)方法。
setContentLength：設(shè)置Content-Length頭。對于支持持久HTTP連接的瀏覽器來說，這個(gè)函數(shù)是很有用的。
addCookie：設(shè)置一個(gè)Cookie(Servlet API中沒有setCookie方法，因?yàn)閼?yīng)答往往包含多個(gè)Set-Cookie頭)。
3.響應(yīng)體
響應(yīng)體就是響應(yīng)的消息體，如果是純數(shù)據(jù)就是返回純數(shù)據(jù)，如果請求的是HTML頁面，那么返回的就是HTML代碼，如果是JS就是JS代碼，如此之類
16. Http和Https的區(qū)別
Http協(xié)議運(yùn)行在TCP之上，明文傳輸，客戶端與服務(wù)器端都無法驗(yàn)證對方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，運(yùn)行于SSL上，SSL運(yùn)行于TCP之上，是添加了加密和認(rèn)證機(jī)制的HTTP。二者之間存在如下不同：
端口不同：Http與Http使用不同的連接方式，用的端口也不一樣，前者是80，后者是443；
資源消耗：和HTTP通信相比，Https通信會(huì)由于加減密處理消耗更多的CPU和內(nèi)存資源；
開銷：Https通信需要證書，而證書一般需要向認(rèn)證機(jī)構(gòu)購買；
Https的加密機(jī)制是一種共享密鑰加密和公開密鑰加密并用的混合加密機(jī)制。
- 端口 ：
HTTP的URL由“http://”起始且默認(rèn)使用端口80，而HTTPS的URL由“https://”起始且默認(rèn)使用端口443。 - 安全性和資源消耗：
HTTP協(xié)議運(yùn)行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗(yàn)證對方的身份。HTTPS是運(yùn)行在SSL/TLS之上的HTTP協(xié)議，SSL/TLS 運(yùn)行在TCP之上。所有傳輸?shù)膬?nèi)容都經(jīng)過加密，加密采用對稱加密，但對稱加密的密鑰用服務(wù)器方的證書進(jìn)行了非對稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費(fèi)更多服務(wù)器資源。
- 對稱加密：密鑰只有一個(gè)，加密解密為同一個(gè)密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
- 非對稱加密：密鑰成對出現(xiàn)（且根據(jù)公鑰無法推知私鑰，根據(jù)私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
https的底層原理
17. 對稱加密與非對稱加密
對稱密鑰加密是指加密和解密使用同一個(gè)密鑰的方式，這種方式存在的最大問題就是密鑰發(fā)送問題，即如何安全地將密鑰發(fā)給對方；而非對稱加密是指使用一對非對稱密鑰，即公鑰和私鑰，公鑰可以隨意發(fā)布，但私鑰只有自己知道。發(fā)送密文的一方使用對方的公鑰進(jìn)行加密處理，對方接收到加密信息后，使用自己的私鑰進(jìn)行解密。
由于非對稱加密的方式不需要發(fā)送用來解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，它非常的慢，所以我們還是要用對稱加密來傳送消息，但對稱加密所使用的密鑰我們可以通過非對稱加密的方式發(fā)送出去。
18. Get與POST的區(qū)別
GET與POST是我們常用的兩種HTTP Method，二者之間的區(qū)別主要包括如下五個(gè)方面：
(1). 從功能上講，GET一般用來從服務(wù)器上獲取資源，POST一般用來更新服務(wù)器上的資源；
(2). 從REST服務(wù)角度上說，GET是冪等的，即讀取同一個(gè)資源，總是得到相同的數(shù)據(jù)，而POST不是冪等的，因?yàn)槊看握埱髮Y源的改變并不是相同的；進(jìn)一步地，GET不會(huì)改變服務(wù)器上的資源，而POST會(huì)對服務(wù)器資源進(jìn)行改變；
(3). 從請求參數(shù)形式上看，GET請求的數(shù)據(jù)會(huì)附在URL之后，即將請求數(shù)據(jù)放置在HTTP報(bào)文的 請求頭 中，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連。特別地，如果數(shù)據(jù)是英文字母/數(shù)字，原樣發(fā)送；否則，會(huì)將其編碼為 application/x-www-form-urlencoded MIME 字符串(如果是空格，轉(zhuǎn)換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進(jìn)制表示的ASCII)；而POST請求會(huì)把提交的數(shù)據(jù)則放置在是HTTP請求報(bào)文的 請求體 中。
(4). 就安全性而言，POST的安全性要比GET的安全性高，因?yàn)镚ET請求提交的數(shù)據(jù)將明文出現(xiàn)在URL上，而且POST請求參數(shù)則被包裝到請求體中，相對更安全。
(5). 從請求的大小看，GET請求的長度受限于瀏覽器或服務(wù)器對URL長度的限制，允許發(fā)送的數(shù)據(jù)量比較小，而POST請求則是沒有大小限制的。
HTTP協(xié)議的響應(yīng)報(bào)文由狀態(tài)行、響應(yīng)頭部和響應(yīng)包體組成，其響應(yīng)狀態(tài)碼總體描述如下：
1xx：指示信息--表示請求已接收，繼續(xù)處理。
2xx：成功--表示請求已被成功接收、理解、接受。
3xx：重定向--要完成請求必須進(jìn)行更進(jìn)一步的操作。
4xx：客戶端錯(cuò)誤--請求有語法錯(cuò)誤或請求無法實(shí)現(xiàn)。
5xx：服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請求。常見狀態(tài)代碼、狀態(tài)描述的詳細(xì)說明如下。
200 OK：客戶端請求成功。
206 partial content服務(wù)器已經(jīng)正確處理部分GET請求，實(shí)現(xiàn)斷點(diǎn)續(xù)傳或同時(shí)分片下載，該請求必須包含Range請求頭來指示客戶端期望得到的范圍
300 multiple choices（可選重定向）:被請求的資源有一系列可供選擇的反饋信息，由瀏覽器/用戶自行選擇其中一個(gè)。
301 moved permanently（永久重定向）：該資源已被永久移動(dòng)到新位置，將來任何對該資源的訪問都要使用本響應(yīng)返回的若干個(gè)URI之一。
302 move temporarily(臨時(shí)重定向)：請求的資源現(xiàn)在臨時(shí)從不同的URI中獲得，
304：not modified :如果客戶端發(fā)送一個(gè)待條件的GET請求并且該請求以經(jīng)被允許，而文檔內(nèi)容未被改變，則返回304,該響應(yīng)不包含包體（即可直接使用緩存）。
403 Forbidden：服務(wù)器收到請求，但是拒絕提供服務(wù)。t Found：請求資源不存在，舉個(gè)例子：輸入了錯(cuò)誤的URL。
HTTP長連接,短連接
在HTTP/1.0中默認(rèn)使用短連接。也就是說，客戶端和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。當(dāng)客戶端瀏覽器訪問的某個(gè)HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個(gè)Web資源，瀏覽器就會(huì)重新建立一個(gè)HTTP會(huì)話。而從HTTP/1.1起，默認(rèn)使用長連接，用以保持連接特性。使用長連接的HTTP協(xié)議，會(huì)在響應(yīng)頭加入這行代碼：Connection:keep-alive在使用長連接的情況下，當(dāng)一個(gè)網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，客戶端再次訪問這個(gè)服務(wù)器時(shí)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長連接需要客戶端和服務(wù)端都支持長連接。HTTP協(xié)議的長連接和短連接，實(shí)質(zhì)上是TCP協(xié)議的長連接和短連接。
