計算機網絡

1. 在瀏覽器中輸入url地址 ->> 顯示主頁的過程,整個過程會使用哪些協議

image.jpeg

整體來講分爲如下幾個過程:

1. DNS解析
2. TCP鏈接
3. 發送HTTP請求
4. 服務器處理請求並返回HTTP報文
5. 瀏覽器解析渲染頁面
6. 鏈接結束

在瀏覽器中輸入網址以後執行會發生什麼？

1. DNS解析，找到對應ip地址
2. 客戶端發起http/https請求,而後交給傳輸層
3. 傳輸層將請求分紅報文段，添加目標源和端口，並隨機用一個本地接口封裝進報頭，而後交給網絡層。
4. 網絡層加上雙方的ip地址信息，並負責路由分發。
5. 鏈路層中，包經過鏈路層發送到路由器，經過鄰居協議查找給定IP地址的MAC地址，而後發送ARP請求查找目的地址，若是獲得迴應後就可使用ARP的請求應答交換的IP數據包進行傳輸了，而後發送IP數據包到達服務器的地址。

各類協議與HTTP協議之間的關係通常面試官會經過這樣的問題來考察你對計算機網絡知識體系的理解。

圖片來源：《圖解HTTP》

Image.png

2.TCP/IP協議層

image.png

image.png

image.jpeg

1.1 應用層
應用層(application-layer）的任務是經過應用進程間的交互來完成特定網絡應用。應用層協議定義的是應用進程（進程：主機中正在運行的程序）間的通訊和交互的規則。對於不一樣的網絡應用須要不一樣的應用層協議。在互聯網中應用層協議不少，如域名系統DNS，支持萬維網應用的 HTTP協議，支持電子郵件的 SMTP協議等等。咱們把應用層交互的數據單元稱爲報文。
域名系統

域名系統(Domain Name System縮寫 DNS，Domain Name被譯爲域名)是因特網的一項核心服務，它做爲能夠將域名和IP地址相互映射的一個分佈式數據庫，可以令人更方便的訪問互聯網，而不用去記住可以被機器直接讀取的IP數串。（百度百科）例如：一個公司的 Web 網站可看做是它在網上的門戶，而域名就至關於其門牌地址，一般域名都使用該公司的名稱或簡稱。例如上面提到的微軟公司的域名，相似的還有：IBM 公司的域名是 www.ibm.com、Oracle 公司的域名是 www.oracle.com、Cisco公司的域名是 www.cisco.com 等。

HTTP協議

超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最爲普遍的一種網絡協議。全部的 WWW（萬維網） 文件都必須遵照這個標準。設計 HTTP 最初的目的是爲了提供一種發佈和接收 HTML 頁面的方法。（百度百科）1.2 運輸層
運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通訊提供通用的數據傳輸服務。應用進程利用該服務傳送應用層報文。「通用的」是指並不針對某一個特定的網絡應用，而是多種應用可使用同一個運輸層服務。因爲一臺主機可同時運行多個線程，所以運輸層有複用和分用的功能。所謂複用就是指多個應用層進程可同時使用下面運輸層的服務，分用和複用相反，是運輸層把收到的信息分別交付上面應用層中的相應進程。

運輸層
主要使用如下兩種協議:

1. 傳輸控制協議 TCP（Transmission Control Protocol）--提供面向鏈接的，可靠的數據傳輸服務。
2. 用戶數據協議 UDP（User Datagram Protocol）--提供無鏈接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）。

1.3 網絡層
在 計算機網絡中進行通訊的兩個計算機之間可能會通過不少個數據鏈路，也可能還要通過不少通訊子網。網絡層的任務就是選擇合適的網間路由和交換結點， 確保數據及時傳送。 在發送數據時，網絡層把運輸層產生的報文段或用戶數據報封裝成分組和包進行傳送。在 TCP/IP 體系結構中，因爲網絡層使用 IP 協議，所以分組也叫 IP 數據報 ，簡稱 數據報。
這裏要注意：不要把運輸層的「用戶數據報 UDP 」和網絡層的「 IP 數據報」弄混。另外，不管是哪一層的數據單元，均可籠統地用「分組」來表示。
這裏強調指出，網絡層中的「網絡」二字已經不是咱們一般談到的具體網絡，而是指計算機網絡體系結構模型中第三層的名稱.
互聯網是由大量的異構（heterogeneous）網絡經過路由器（router）相互鏈接起來的。互聯網使用的網絡層協議是無鏈接的網際協議（Intert Protocol）和許多路由選擇協議，所以互聯網的網絡層也叫作網際層或IP層。
1.4 數據鏈路層
數據鏈路層(data link layer)一般簡稱爲鏈路層。兩臺主機之間的數據傳輸，老是在一段一段的鏈路上傳送的，這就須要使用專門的鏈路層的協議。 在兩個相鄰節點之間傳送數據時，數據鏈路層將網絡層交下來的 IP 數據報組裝程幀，在兩個相鄰節點間的鏈路上傳送幀。每一幀包括數據和必要的控制信息（如同步信息，地址信息，差錯控制等）。
在接收數據時，控制信息使接收端可以知道一個幀從哪一個比特開始和到哪一個比特結束。這樣，數據鏈路層在收到一個幀後，就可從中提出數據部分，上交給網絡層。 控制信息還使接收端可以檢測到所收到的幀中有偏差錯。若是發現差錯，數據鏈路層就簡單地丟棄這個出了差錯的幀，以免繼續在網絡中傳送下去白白浪費網絡資源。若是須要改正數據在鏈路層傳輸時出現差錯（這就是說，數據鏈路層不只要檢錯，並且還要糾錯），那麼就要採用可靠性傳輸協議來糾正出現的差錯。這種方法會使鏈路層的協議複雜些。
1.5 物理層
在物理層上所傳送的數據單位是比特。 物理層(physical layer)的做用是實現相鄰計算機節點之間比特流的透明傳送，儘量屏蔽掉具體傳輸介質和物理設備的差別。 使其上面的數據鏈路層沒必要考慮網絡的具體傳輸介質是什麼。「透明傳送比特流」表示經實際電路傳送後的比特流沒有發生變化，對傳送的比特流來講，這個電路好像是看不見的。
在互聯網使用的各類協中最重要和最著名的就是 TCP/IP 兩個協議。如今人們常常提到的TCP/IP並不必定單指TCP和IP這兩個具體的協議，而每每表示互聯網所使用的整個TCP/IP協議族。

1). 物理層
　　參考模型的最低層，也是OSI模型的第一層，實現了相鄰計算機節點之間比特流的透明傳送，並儘量地屏蔽掉具體傳輸介質和物理設備的差別，使其上層(數據鏈路層)沒必要關心網絡的具體傳輸介質。

2). 數據鏈路層（data link layer）
　　接收來自物理層的位流形式的數據，並封裝成幀，傳送到上一層；一樣，也未來自上層的數據幀，拆裝爲位流形式的數據轉發到物理層。這一層在物理層提供的比特流的基礎上，經過差錯控制、流量控制方法，使有差錯的物理線路變爲無差錯的數據鏈路，即提供可靠的經過物理介質傳輸數據的方法。

3). 網絡層
　　將網絡地址翻譯成對應的物理地址，並經過路由選擇算法爲分組經過通訊子網選擇最適當的路徑。

4). 傳輸層（transport layer）
　　在源端與目的端之間提供可靠的透明數據傳輸，使上層服務用戶沒必要關係通訊子網的實現細節。在協議棧中，傳輸層位於網絡層之上，傳輸層協議爲不一樣主機上運行的進程提供邏輯通訊，而網絡層協議爲不一樣主機提供邏輯通訊，以下圖所示。
　　實際上，網絡層能夠看做是傳輸層的一部分，其爲傳輸層提供服務。但對於終端系統而言，網絡層對它們而言是透明的，它們知道傳輸層的存在，也就是說，在邏輯上它們認爲是傳輸層爲它們提供了端對端的通訊，這也是分層思想的妙處。

5). 會話層（Session Layer）
　　會話層是OSI模型的第五層，是用戶應用程序和網絡之間的接口，負責在網絡中的兩節點之間創建、維持和終止通訊。

6). 表示層（Presentation Layer）：數據的編碼，壓縮和解壓縮，數據的加密和解
　　表示層是OSI模型的第六層，它對來自應用層的命令和數據進行解釋，以確保一個系統的應用層所發送的信息能夠被另外一個系統的應用層讀取。

7). 應用層（Application layer）：爲用戶的應用進程提供網絡通訊服務

3. TCP對應的應用層協議

FTP：定義了文件傳輸協議，使用21端口。常說某某計算機開了FTP服務即是啓動了文件傳輸服務。下載文件，上傳主頁，都要用到FTP服務。

Telnet：它是一種用於遠程登錄的端口，用戶能夠以本身的身份遠程鏈接到計算機上，經過這種端口能夠提供一種基於DOS模式下的通訊服務。如之前的BBS是-純字符界面的，支持BBS的服務器將23端口打開，對外提供服務。

SMTP：定義了簡單郵件傳送協議，如今不少郵件服務器都用的是這個協議，用於發送郵件。如常見的免費郵件服務中用的就是這個郵件服務端口，因此在電子郵件設置-中常看到有這麼SMTP端口設置這個欄，服務器開放的是25號端口。

POP3：它是和SMTP對應，POP3用於接收郵件。一般狀況下，POP3協議所用的是110端口。也是說，只要你有相應的使用POP3協議的程序（例如Fo-xmail或Outlook），就能夠不以Web方式登錄進郵箱界面，直接用郵件程序就能夠收到郵件（如是163郵箱就沒有必要先進入網易網站，再進入本身的郵-箱來收信）。

HTTP：從Web服務器傳輸超文本到本地瀏覽器的傳送協議。

4. UDP對應的應用層協議

DNS：用於域名解析服務，將域名地址轉換爲IP地址。DNS用的是53號端口。

SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。因爲網絡設備不少，無鏈接的服務就體現出其優點。

TFTP(Trival File Transfer Protocal)：簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務。

5. TCP/UDP

TCP/UDP都是是傳輸層協議，可是二者具備不一樣的特性，同時也具備不一樣的應用場景

image.jpeg

何時應該使用TCP

當對網絡通信質量有要求的時候，好比：整個數據要準確無誤的傳遞給對方，這每每用於一些要求可靠的應用，好比HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。

何時應該使用UDP

當對網絡通信質量要求不高的時候，要求網絡通信速度能儘可能的快，這時就可使用UDP。

8..三次握手，四次揮手

image.jpeg

image.jpeg

9. 爲何要三次握手

三次握手的目的是創建可靠的通訊信道，說到通信，簡單來講就是數據的發送與接收，而三次握手最主要的目的就是雙方確認本身與對方的發送與接收是正常的。

第一次握手：Client 什麼都不能確認；Server 確認了對方發送正常，本身接收正常。
第二次握手：Client 確認了：本身發送、接收正常，對方發送、接收正常；Server 確認了：本身接收正常，對方發送正常
第三次握手：Client 確認了：本身發送、接收正常，對方發送、接收正常；Server 確認了：本身發送、接收正常，對方發送接收正常
因此三次握手就能確認雙發收發功能都正常，缺一不可。

10.爲何要四次揮手

任何一方均可以在數據傳送結束後發出鏈接釋放的通知，待對方確認後進入半關閉狀態。當另外一方也沒有數據再發送的時候，則發出鏈接釋放通知，對方確認後就徹底關閉了TCP鏈接。

舉個例子：A 和 B 打電話，通話即將結束後，A 說「我沒啥要說的了」，B回答「我知道了」，可是 B 可能還會有要說的話，A 不能要求 B 跟着本身的節奏結束通話，因而 B 可能又巴拉巴拉說了一通，最後 B 說「我說完了」，A 回答「知道了」，這樣通話纔算結束。

11.對於可靠性，TCP經過如下方式進行保證：

1. 數據包校驗：目的是檢測數據在傳輸過程當中的任何變化，若校驗出包有錯，則丟棄報文段而且不給出響應，這時TCP發送數據端超時後會重發數據；
2. 對失序數據包重排序：既然TCP報文段做爲IP數據報來傳輸，而IP數據報的到達可能會失序，所以TCP報文段的到達也可能會失序。TCP將對失序數據進行從新排序，而後才交給應用層；
3. 丟棄重複數據：對於重複數據，可以丟棄重複數據；
4. 應答機制：當TCP收到發自TCP鏈接另外一端的數據，它將發送一個確認。這個確認不是當即發送，一般將推遲幾分之一秒；
5. 超時重發：當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。若是不能及時收到一個確認，將重發這個報文段；
6. 流量控制：TCP鏈接的每一方都有固定大小的緩衝空間。TCP的接收端只容許另外一端發送接收端緩衝區所能接納的數據，這能夠防止較快主機導致較慢主機的緩衝區溢出，這就是流量控制。TCP使用的流量控制協議是可變大小的滑動窗口協議。

12.超時重發

當發送者向接收者發包後，若是過了一段時間(超時時間)依然沒有收到消息，就當作本次包丟失，須要從新補發。
而且若是一次性發了三個包，只要最後一個包確認收到以後就默認前面兩個也收到了。

13. 滑動窗口

假設一次性發送包的大小爲3，那麼每次能夠發3個包，並且能夠邊發邊接收，這樣就會加強效率。這裏的 3 就是滑動窗口的大小，這樣的發送方式也叫滑動窗口協議。

14.默認端口號

1.HTTP協議代理服務器經常使用端口號：80/8080/3128/8081/9098
2.SOCKS代理協議服務器經常使用端口號：1080
3.FTP（文件傳輸）協議代理服務器經常使用端口號：21
4.Telnet（遠程登陸）協議代理服務器經常使用端口號：23
HTTP服務器，默認端口號爲80/tcp（木馬Executor開放此端口）
HTTPS（securely transferring web pages）服務器，默認端口號爲443/tcp 443/udp

IP地址與MAC地址的區別

IP地址是指互聯網協議地址（Internet Protocol Address）IP Address的縮寫。IP地址是IP協議提供的一種統一的地址格式，它爲互聯網上的每個網絡和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差別。
MAC 地址又稱爲物理地址、硬件地址，用來定義網絡設備的位置。網卡的物理地址一般是由網卡生產廠家寫入網卡的，具備全球惟一性。MAC地址用於在網絡中惟一標示一個網卡，一臺電腦會有一或多個網卡，每一個網卡都須要有一個惟一的MAC地址。

15.HTTP請求/響應報文結構

請求

HTTP請求報文
一個HTTP請求報文由四個部分組成：請求行、請求頭部、空行、請求數據。

1.請求行

請求行由請求方法字段、URL字段和HTTP協議版本字段3個字段組成，它們用空格分隔。好比 GET /data/info.html HTTP/1.1
方法字段就是HTTP使用的請求方法，好比常見的GET/POST
其中HTTP協議版本有兩種：HTTP1.0/HTTP1.1 能夠這樣區別：
HTTP1.0對於每一個鏈接都只能傳送一個請求和響應，請求就會關閉，HTTP1.0沒有Host字段;而HTTP1.1在同一個鏈接中能夠傳送多個請求和響應，多個請求能夠重疊和同時進行，HTTP1.1必須有Host字段。

2.請求頭部

HTTP客戶程序(例如瀏覽器)，向服務器發送請求的時候必須指明請求類型(通常是GET或者 POST)。若有必要，客戶程序還能夠選擇發送其餘的請求頭。大多數請求頭並非必需的，但Content-Length除外。對於POST請求來講 Content-Length必須出現。
常見的請求頭字段含義：
Accept： 瀏覽器可接受的MIME類型。
Accept-Charset：瀏覽器可接受的字符集。
Accept-Encoding：瀏覽器可以進行解碼的數據編碼方式，好比gzip。Servlet可以向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這能夠減小5到10倍的下載時間。
Accept-Language：瀏覽器所但願的語言種類，當服務器可以提供一種以上的語言版本時要用到。
Authorization：受權信息，一般出如今對服務器發送的WWW-Authenticate頭的應答中。
Content-Length：表示請求消息正文的長度。
Host： 客戶機經過這個頭告訴服務器，想訪問的主機名。Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，不然系統會以400狀態碼返回。
If-Modified-Since：客戶機經過這個頭告訴服務器，資源的緩存時間。只有當所請求的內容在指定的時間後又通過修改才返回它，不然返回304「Not Modified」應答。
Referer：客戶機經過這個頭告訴服務器，它是從哪一個資源來訪問服務器的(防盜鏈)。包含一個URL，用戶從該URL表明的頁面出發訪問當前請求的頁面。
User-Agent：User-Agent頭域的內容包含發出請求的用戶信息。瀏覽器類型，若是Servlet返回的內容與瀏覽器類型有關則該值很是有用。
Cookie：客戶機經過這個頭能夠向服務器帶數據，這是最重要的請求頭信息之一。
Pragma：指定「no-cache」值表示服務器必須返回一個刷新後的文檔，即便它是代理服務器並且已經有了頁面的本地拷貝。
From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它。
Connection：處理完此次請求後是否斷開鏈接仍是繼續保持鏈接。若是Servlet看到這裏的值爲「Keep- Alive」，或者看到請求使用的是HTTP 1.1(HTTP 1.1默認進行持久鏈接)，它就能夠利用持久鏈接的優勢，當頁面包含多個元素時(例如Applet，圖片)，顯著地減小下載所須要的時間。要實現這一點，Servlet須要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入 ByteArrayOutputStream，而後在正式寫出內容以前計算它的大小。
Range：Range頭域能夠請求實體的一個或者多個子範圍。例如，
表示頭500個字節：bytes=0-499
表示第二個500字節：bytes=500-999
表示最後500個字節：bytes=-500
表示500字節之後的範圍：bytes=500-
第一個和最後一個字節：bytes=0-0,-1
同時指定幾個範圍：bytes=500-600,601-999
可是服務器能夠忽略此請求頭，若是無條件GET包含Range請求頭，響應會以狀態碼206(PartialContent)返回而不是以200 (OK)。
UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標準的請求頭，表示屏幕大小、顏色深度、操做系統和CPU類型。
3.空行
它的做用是經過一個空行，告訴服務器請求頭部到此爲止。

4.請求數據
若方法字段是GET，則此項爲空，沒有數據
若方法字段是POST,則一般來講此處放置的就是要提交的數據
好比要使用POST方法提交一個表單，其中有user字段中數據爲「admin」, password字段爲123456，那麼這裏的請求數據就是 user=admin&password=123456，使用&來鏈接各個字段。

響應

上面是POST方法，它的請求行URL段中通常是沒有參數的，參數放在了報文體中。而GET方法的參數直接置於請求行URL中，報文體則爲空。

HTTP響應報文
一樣的，HTTP響應報文也由三部分組成：響應行、響應頭、響應體

1.響應行

響應行通常由協議版本、狀態碼及其描述組成 好比 HTTP/1.1 200 OK
其中協議版本HTTP/1.1或者HTTP/1.0，200就是它的狀態碼，OK則爲它的描述。
//常見狀態碼：
100~199：表示成功接收請求，要求客戶端繼續提交下一次請求才能完成整個處理過程。
200~299：表示成功接收請求並已完成整個處理過程。經常使用200
300~399：爲完成請求，客戶需進一步細化請求。例如：請求的資源已經移動一個新地址、經常使用302(意味着你請求我，我讓你去找別人),307和304(我不給你這個資源，本身拿緩存)
400~499：客戶端的請求有錯誤，經常使用404(意味着你請求的資源在web服務器中沒有)403(服務器拒絕訪問，權限不夠)
500~599：服務器端出現錯誤，經常使用500
更詳細的狀態碼信息

2.響應頭

響應頭用於描述服務器的基本信息，以及數據的描述，服務器經過這些數據的描述信息，能夠通知客戶端如何處理等一下子它回送的數據。
設置HTTP響應頭每每和狀態碼結合起來。例如，有好幾個表示「文檔位置已經改變」的狀態代碼都伴隨着一個Location頭，而401(Unauthorized)狀態代碼則必須伴隨一個WWW-Authenticate頭。然而，即便在沒有設置特殊含義的狀態代碼時，指定應答頭也是頗有用的。應答頭能夠用來完成：設置Cookie，指定修改日期，指示瀏覽器按照指定的間隔刷新頁面，聲明文檔的長度以便利用持久HTTP鏈接，……等等許多其餘任務。
常見的響應頭字段含義：
Allow：服務器支持哪些請求方法(如GET、POST等)。
Content-Encoding：文檔的編碼(Encode)方法。只有在解碼以後才能夠獲得Content-Type頭指定的內容類型。利用gzip壓縮文檔可以顯著地減小HTML文檔的下載時間。Java的GZIPOutputStream能夠很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE四、IE5才支持它。所以，Servlet應該經過查看Accept-Encoding頭(即request.getHeader(「Accept- Encoding」))檢查瀏覽器是否支持gzip，爲支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，爲其餘瀏覽器返回普通頁面。
Content-Length：表示內容長度。只有當瀏覽器使用持久HTTP鏈接時才須要這個數據。若是你想要利用持久鏈接的優點，能夠把輸出文檔寫入 ByteArrayOutputStram，完成後查看其大小，而後把該值放入Content-Length頭，最後經過byteArrayStream.writeTo(response.getOutputStream()發送內容。
Content- Type：表示後面的文檔屬於什麼MIME類型。Servlet默認爲text/plain，但一般須要顯式地指定爲text/html。因爲常常要設置 Content-Type，所以HttpServletResponse提供了一個專用的方法setContentType。
Date：當前的GMT時間，例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時，換算成本地時間，須要知道用戶所在的時區。你能夠用setDateHeader來設置這個頭以免轉換時間格式的麻煩。
Expires：告訴瀏覽器把回送的資源緩存多長時間，-1或0則是不緩存。
Last-Modified：文檔的最後改動時間。客戶能夠經過If-Modified-Since請求頭提供一個日期，該請求將被視爲一個條件GET，只有改動時間遲於指定時間的文檔纔會返回，不然返回一個304(Not Modified)狀態。Last-Modified也可用setDateHeader方法來設置。
Location：這個頭配合302狀態碼使用，用於重定向接收者到一個新URI地址。表示客戶應當到哪裏去提取文檔。Location一般不是直接設置的，而是經過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼爲302。
Refresh：告訴瀏覽器隔多久刷新一次，以秒計。
Server：服務器經過這個頭告訴瀏覽器服務器的類型。Server響應頭包含處理請求的原始服務器的軟件信息。此域能包含多個產品標識和註釋，產品標識通常按照重要性排序。Servlet通常不設置這個值，而是由Web服務器本身設置。
Set-Cookie：設置和頁面關聯的Cookie。Servlet不該使用response.setHeader(「Set-Cookie」, …)，而是應使用HttpServletResponse提供的專用方法addCookie。
Transfer-Encoding：告訴瀏覽器數據的傳送格式。
WWW-Authenticate：客戶應該在Authorization頭中提供什麼類型的受權信息?在包含401(Unauthorized)狀態行的應答中這個頭是必需的。例如，response.setHeader(「WWW-Authenticate」, 「BASIC realm=\」executives\」「)。注意Servlet通常不進行這方面的處理，而是讓Web服務器的專門機制來控制受密碼保護頁面的訪問。
注：設置應答頭最經常使用的方法是HttpServletResponse的setHeader，該方法有兩個參數，分別表示應答頭的名字和值。和設置狀態代碼類似，設置應答頭應該在發送任何文檔內容以前進行。
setDateHeader方法和setIntHeadr方法專門用來設置包含日期和整數值的應答頭，前者避免了把Java時間轉換爲GMT時間字符串的麻煩，後者則避免了把整數轉換爲字符串的麻煩。
HttpServletResponse還提供了許多設置
setContentType：設置Content-Type頭。大多數Servlet都要用到這個方法。
setContentLength：設置Content-Length頭。對於支持持久HTTP鏈接的瀏覽器來講，這個函數是頗有用的。
addCookie：設置一個Cookie(Servlet API中沒有setCookie方法，由於應答每每包含多個Set-Cookie頭)。
3.響應體

響應體就是響應的消息體，若是是純數據就是返回純數據，若是請求的是HTML頁面，那麼返回的就是HTML代碼，若是是JS就是JS代碼，如此之類

16. Http和Https的區別

Http協議運行在TCP之上，明文傳輸，客戶端與服務器端都沒法驗證對方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，運行於SSL上，SSL運行於TCP之上，是添加了加密和認證機制的HTTP。兩者之間存在以下不一樣：
端口不一樣：Http與Http使用不一樣的鏈接方式，用的端口也不同，前者是80，後者是443；
資源消耗：和HTTP通訊相比，Https通訊會因爲加減密處理消耗更多的CPU和內存資源；
開銷：Https通訊須要證書，而證書通常須要向認證機構購買；　
Https的加密機制是一種共享密鑰加密和公開密鑰加密並用的混合加密機制。

1. 端口 ：
   HTTP的URL由「http://」起始且默認使用端口80，而HTTPS的URL由「https://」起始且默認使用端口443。
2. 安全性和資源消耗：
   HTTP協議運行在TCP之上，全部傳輸的內容都是明文，客戶端和服務器端都沒法驗證對方的身份。HTTPS是運行在SSL/TLS之上的HTTP協議，SSL/TLS 運行在TCP之上。全部傳輸的內容都通過加密，加密採用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。因此說，HTTP 安全性沒有 HTTPS高，可是 HTTPS 比HTTP耗費更多服務器資源。

• 對稱加密：密鑰只有一個，加密解密爲同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
• 非對稱加密：密鑰成對出現（且根據公鑰沒法推知私鑰，根據私鑰也沒法推知公鑰），加密解密使用不一樣密鑰（公鑰加密須要私鑰解密，私鑰加密須要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

https的底層原理

image.png

image.png

17. 對稱加密與非對稱加密

　　對稱密鑰加密是指加密和解密使用同一個密鑰的方式，這種方式存在的最大問題就是密鑰發送問題，即如何安全地將密鑰發給對方；而非對稱加密是指使用一對非對稱密鑰，即公鑰和私鑰，公鑰能夠隨意發佈，但私鑰只有本身知道。發送密文的一方使用對方的公鑰進行加密處理，對方接收到加密信息後，使用本身的私鑰進行解密。
　　因爲非對稱加密的方式不須要發送用來解密的私鑰，因此能夠保證安全性；可是和對稱加密比起來，它很是的慢，因此咱們仍是要用對稱加密來傳送消息，但對稱加密所使用的密鑰咱們能夠經過非對稱加密的方式發送出去。

18. Get與POST的區別

　GET與POST是咱們經常使用的兩種HTTP Method，兩者之間的區別主要包括以下五個方面：
(1). 從功能上講，GET通常用來從服務器上獲取資源，POST通常用來更新服務器上的資源；
(2). 從REST服務角度上說，GET是冪等的，即讀取同一個資源，老是獲得相同的數據，而POST不是冪等的，由於每次請求對資源的改變並非相同的；進一步地，GET不會改變服務器上的資源，而POST會對服務器資源進行改變；
(3). 從請求參數形式上看，GET請求的數據會附在URL以後，即將請求數據放置在HTTP報文的 請求頭 中，以?分割URL和傳輸數據，參數之間以&相連。特別地，若是數據是英文字母/數字，原樣發送；不然，會將其編碼爲 application/x-www-form-urlencoded MIME 字符串(若是是空格，轉換爲+，若是是中文/其餘字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX爲該符號以16進製表示的ASCII)；而POST請求會把提交的數據則放置在是HTTP請求報文的 請求體 中。
(4). 就安全性而言，POST的安全性要比GET的安全性高，由於GET請求提交的數據將明文出如今URL上，並且POST請求參數則被包裝到請求體中，相對更安全。
(5). 從請求的大小看，GET請求的長度受限於瀏覽器或服務器對URL長度的限制，容許發送的數據量比較小，而POST請求則是沒有大小限制的。

HTTP協議的響應報文由狀態行、響應頭部和響應包體組成，其響應狀態碼整體描述以下：

1xx：指示信息--表示請求已接收，繼續處理。
2xx：成功--表示請求已被成功接收、理解、接受。
3xx：重定向--要完成請求必須進行更進一步的操做。
4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現。
5xx：服務器端錯誤--服務器未能實現合法的請求。常見狀態代碼、狀態描述的詳細說明以下。
200 OK：客戶端請求成功。
206 partial content服務器已經正確處理部分GET請求，實現斷點續傳或同時分片下載，該請求必須包含Range請求頭來指示客戶端指望獲得的範圍
300 multiple choices（可選重定向）:被請求的資源有一系列可供選擇的反饋信息，由瀏覽器/用戶自行選擇其中一個。
301 moved permanently（永久重定向）：該資源已被永久移動到新位置，未來任何對該資源的訪問都要使用本響應返回的若干個URI之一。
302 move temporarily(臨時重定向)：請求的資源如今臨時從不一樣的URI中得到，
304：not modified :若是客戶端發送一個待條件的GET請求而且該請求以經被容許，而文檔內容未被改變，則返回304,該響應不包含包體（便可直接使用緩存）。
403 Forbidden：服務器收到請求，可是拒絕提供服務。t Found：請求資源不存在，舉個例子：輸入了錯誤的URL。

HTTP長鏈接,短鏈接

在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協議的長鏈接和短鏈接。