1. 在瀏覽器中輸入url地址 ->> 顯示主頁的過程,整個過程會使用哪些協議
總體來說分為以下幾個過程:
- DNS解析
- TCP連接
- 發送HTTP請求
- 服務器處理請求並返回HTTP報文
- 瀏覽器解析渲染頁面
- 連接結束
在瀏覽器中輸入網址之后執行會發生什么？
- DNS解析，找到對應ip地址
- 客戶端發起http/https請求,然后交給傳輸層
- 傳輸層將請求分成報文段，添加目標源和端口，並隨機用一個本地接口封裝進報頭，然后交給網絡層。
- 網絡層加上雙方的ip地址信息，並負責路由分發。
- 鏈路層中，包通過鏈路層發送到路由器，通過鄰居協議查找給定IP地址的MAC地址，然后發送ARP請求查找目的地址，如果得到回應后就可以使用ARP的請求應答交換的IP數據包進行傳輸了，然后發送IP數據包到達服務器的地址。
各種協議與HTTP協議之間的關系一般面試官會通過這樣的問題來考察你對計算機網絡知識體系的理解。
圖片來源：《圖解HTTP》
2.TCP/IP協議層
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)的主要任務就是負責向兩台主機進程之間的通信提供通用的數據傳輸服務。應用進程利用該服務傳送應用層報文。“通用的”是指並不針對某一個特定的網絡應用，而是多種應用可以使用同一個運輸層服務。由於一台主機可同時運行多個線程，因此運輸層有復用和分用的功能。所謂復用就是指多個應用層進程可同時使用下面運輸層的服務，分用和復用相反，是運輸層把收到的信息分別交付上面應用層中的相應進程。
運輸層
主要使用以下兩種協議:
- 傳輸控制協議 TCP（Transmission Control Protocol）--提供面向連接的，可靠的數據傳輸服務。
- 用戶數據協議 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都是是傳輸層協議，但是兩者具有不同的特性，同時也具有不同的應用場景
什么時候應該使用TCP
當對網絡通訊質量有要求的時候，比如：整個數據要准確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。
什么時候應該使用UDP
當對網絡通訊質量要求不高的時候，要求網絡通訊速度能盡量的快，這時就可以使用UDP。
8..三次握手，四次揮手
9. 為什么要三次握手
三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是數據的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。
第一次握手：Client 什么都不能確認；Server 確認了對方發送正常，自己接收正常。
第二次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己接收正常，對方發送正常
第三次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己發送、接收正常，對方發送接收正常
所以三次握手就能確認雙發收發功能都正常，缺一不可。
10.為什么要四次揮手
任何一方都可以在數據傳送結束后發出連接釋放的通知，待對方確認后進入半關閉狀態。當另一方也沒有數據再發送的時候，則發出連接釋放通知，對方確認后就完全關閉了TCP連接。
舉個例子：A 和 B 打電話，通話即將結束后，A 說“我沒啥要說的了”，B回答“我知道了”，但是 B 可能還會有要說的話，A 不能要求 B 跟着自己的節奏結束通話，於是 B 可能又巴拉巴拉說了一通，最后 B 說“我說完了”，A 回答“知道了”，這樣通話才算結束。
11.對於可靠性，TCP通過以下方式進行保證：
- 數據包校驗：目的是檢測數據在傳輸過程中的任何變化，若校驗出包有錯，則丟棄報文段並且不給出響應，這時TCP發送數據端超時后會重發數據；
- 對失序數據包重排序：既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段的到達也可能會失序。TCP將對失序數據進行重新排序，然后才交給應用層；
- 丟棄重復數據：對於重復數據，能夠丟棄重復數據；
- 應答機制：當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒；
- 超時重發：當TCP發出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段；
- 流量控制：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上的IE4、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的加密機制是一種共享密鑰加密和公開密鑰加密並用的混合加密機制。
- 端口 ：
HTTP的URL由“http://”起始且默認使用端口80，而HTTPS的URL由“https://”起始且默認使用端口443。 - 安全性和資源消耗：
HTTP協議運行在TCP之上，所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份。HTTPS是運行在SSL/TLS之上的HTTP協議，SSL/TLS 運行在TCP之上。所有傳輸的內容都經過加密，加密采用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費更多服務器資源。
- 對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
- 非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
https的底層原理
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協議的長連接和短連接。