關(guān)鍵字：Http，Https，TCP，UDP，Socket，面試

一、 Http,Https（應(yīng)用層協(xié)議）

Http協(xié)議，超文本傳送協(xié)議(Hypertext Transfer Protocol )，Http協(xié)議是基于TCP協(xié)議之上的一種應(yīng)用。
Https協(xié)議（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的Http通道，簡單講是Http的安全版。即Http下加入SSL層，Https的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。

Https和Http的區(qū)別主要為以下四點：

1. Https協(xié)議需要到CA（數(shù)字證書簽發(fā)機構(gòu)）申請數(shù)字證書，一般免費證書很少，需要交費。
2. Http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的SSL加密傳輸協(xié)議。
3. Http和Https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4. Http的連接很簡單，是無狀態(tài)的；https協(xié)議是由SSL/TLS（Secure Sockets Layer/Transport Layer Security）+Http協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比Http協(xié)議安全。

Https簡單原理解析（對稱加密，非對稱加密，中間人攻擊，公鑰，私鑰，數(shù)字證書，數(shù)字簽名）： 也許，這樣理解HTTPS更容易

HTTPS要使客戶端與服務(wù)器端的通信過程得到安全保證，必須使用對稱加密算法，但是協(xié)商對稱加密算法的過程，需要使用非對稱加密算法來保證安全，然而直接使用非對稱加密的過程本身也不安全，會有中間人篡改公鑰的可能性，所以客戶端與服務(wù)器不直接使用公鑰，而是使用數(shù)字證書簽發(fā)機構(gòu)頒發(fā)的證書來保證非對稱加密過程本身的安全。這樣通過這些機制協(xié)商出一個非對稱加密算法，就此雙方使用該算法進(jìn)行加密解密。從而解決了客戶端與服務(wù)器端之間的通信安全問題。

二、 網(wǎng)絡(luò)七層模型

20世紀(jì)70年代中，為了優(yōu)化數(shù)據(jù)庫系統(tǒng)設(shè)計，支持?jǐn)?shù)據(jù)庫系統(tǒng)的訪問，美國的一個互聯(lián)網(wǎng)研究小組提出了一個結(jié)構(gòu)化的分布式通信系統(tǒng)體系結(jié)構(gòu)（共七層），他們內(nèi)部稱之為分布式系統(tǒng)體系結(jié)構(gòu)（DSA），1977年英國標(biāo)準(zhǔn)化協(xié)會向國際標(biāo)準(zhǔn)化組織（ISO）提議，為了定義分布處理之間的通信基礎(chǔ)設(shè)施，需要一個標(biāo)準(zhǔn)的體系結(jié)構(gòu)。后來，ISO就開放系統(tǒng)互聯(lián)（OSI）問題成立了一個專委會（TC 97, Subcomittee 16），指定由美國國家標(biāo)準(zhǔn)協(xié)會（ANSI）開發(fā)一個標(biāo)準(zhǔn)草案。1978年3月，在ISO的OSI專委會在華盛頓召開的會議上，與會專家很快達(dá)成了共識，認(rèn)為這個分層的體系結(jié)構(gòu)能夠滿足開放式系統(tǒng)的大多數(shù)需求，而且具有可擴展的能力，能夠滿足新的需求。于是，1978年發(fā)布了這個臨時版本，1979年稍作細(xì)化之后，成了最終的版本。七層模型內(nèi)容如下，左側(cè)列出的是簡化后的四層模型。

OSI網(wǎng)絡(luò)七層模型

1.實體層：連接網(wǎng)絡(luò)的硬件設(shè)備，就是將電腦連接起來的物理手段. 如光纜/電纜/無線電波
2.數(shù)據(jù)鏈路層 (Link)：建立邏輯連接、進(jìn)行硬件地址尋址、差錯校驗等功能，如32位和64位計算機，他們的解碼方式是不一樣的，數(shù)據(jù)鏈路層就規(guī)定個二進(jìn)制數(shù)據(jù)的解讀方式。
3.網(wǎng)絡(luò)層 (Network)：進(jìn)行邏輯地址尋址，實現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇。網(wǎng)絡(luò)層建立了主機之間的通信，它在網(wǎng)絡(luò)層引入了一套地址機制:網(wǎng)絡(luò)地址.簡稱網(wǎng)址（Ip地址），我們可以通過Ip地址,可以找到唯一的一臺計算機，通過主機MAC地址來接收和發(fā)送信息。
4.傳輸層 (Transport)：定義傳輸數(shù)據(jù)的協(xié)議端口號，以及流控和差錯效驗，定義了端口和端口之間的通信，幫助我們使不同的應(yīng)用程序能夠接收到自己所需要的的數(shù)據(jù)。
5.會話層（Session Layer）：包括建立、管理、終止會話，用來建立和管理應(yīng)用程序之間的通信，實現(xiàn)自動尋址，自動收發(fā)數(shù)據(jù)。
6.表示層（Presentation Layer）：數(shù)據(jù)的表示、安全、壓縮。比如我們要用基于Unix系統(tǒng)的mac電腦給pc機發(fā)送數(shù)據(jù)，表示層為我們解決了通信間語法的問題。
7.應(yīng)用層 (Application)：網(wǎng)絡(luò)服務(wù)與最終用戶的一個接口。比如不同的文件類型要用不同的應(yīng)用程序打開，應(yīng)用層中就規(guī)定了不同應(yīng)用程序的數(shù)據(jù)格式。

三、TCP/IP，IP，TCP，UDP，Socket

IP協(xié)議對應(yīng)于網(wǎng)絡(luò)層，TCP,UDP協(xié)議對應(yīng)于傳輸層，而HTTP協(xié)議對應(yīng)于應(yīng)用層。

TCP/IP協(xié)議是一個協(xié)議簇，由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成。TCP/IP層次模型共分為四層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層

IP協(xié)議（網(wǎng)絡(luò)層協(xié)議），為計算機網(wǎng)絡(luò)相互連接進(jìn)行通信而設(shè)計的協(xié)議。

TCP/UDP(傳輸層協(xié)議)，基于二進(jìn)制流的控制間傳輸協(xié)議：TCP是面向連接的，雖然說網(wǎng)絡(luò)的不安全不穩(wěn)定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上(實際上也很大程度上保證了)保證了連接的可靠性；而UDP不是面向連接的，UDP傳送數(shù)據(jù)前并不與對方建立連接，對接收到的數(shù)據(jù)也不發(fā)送確認(rèn)信號，發(fā)送端不知道數(shù)據(jù)是否會正確接收，當(dāng)然也不用重發(fā)，所以說UDP是無連接的、不可靠的一種數(shù)據(jù)傳輸協(xié)議。

TCP與UDP區(qū)別總結(jié)：
1.TCP是面向連接的；UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接
2.TCP保證數(shù)據(jù)正確性，UDP可能丟包，TCP保證數(shù)據(jù)順序，UDP不保證。
3.UDP具有較好的實時性，傳輸速度比TCP快，適用于對高速傳輸和實時性有較高的通信或廣播通信。
4.TCP對系統(tǒng)資源要求較多，UDP對系統(tǒng)資源要求較少。

Socket相當(dāng)于調(diào)用接口(API)，用來調(diào)取TCP/IP協(xié)議。**

四、使用Socket建立網(wǎng)絡(luò)

網(wǎng)絡(luò)上兩個程序通過雙向通信實現(xiàn)數(shù)據(jù)交換，Socket又叫套接字，每個應(yīng)用程序開啟后，都會在傳輸層端口上綁定一個Socket，不同應(yīng)用程序之間通過端口找到Socket實現(xiàn)數(shù)據(jù)通信。

Socket連接過程分為三個步驟：服務(wù)器監(jiān)聽，客戶端請求，連接確認(rèn)。

1、服務(wù)器監(jiān)聽：服務(wù)器端套接字并不定位具體的客戶端套接字，而是處于等待連接的狀態(tài)，實時監(jiān)控網(wǎng)絡(luò)狀態(tài)，等待客戶端的連接請求。

2、客戶端請求：指客戶端的套接字提出連接請求，要連接的目標(biāo)是服務(wù)器端的套接字。為此，客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字，指出服務(wù)器端套接字的地址和端口號，然后就向服務(wù)器端套接字提出連接請求。

3、連接確認(rèn)：當(dāng)服務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時，就響應(yīng)客戶端套接字的請求，建立一個新的線程，把服務(wù)器端套接字的描述發(fā)給客戶端，一旦客戶端確認(rèn)了此描述，雙方就正式建立連接。

五、 TCP三次握手過程

1.主機A通過向主機B發(fā)送一個含有同步序列號的標(biāo)志位的數(shù)據(jù)段，向主機B請求建立連接。通過這個數(shù)據(jù)段，主機A告訴主機B兩件事:我想要和你通信以及你可以用那個序列號作為起始數(shù)據(jù)段來回應(yīng)我。

2.主機B收到主機A的請求后，用一個帶有確認(rèn)應(yīng)答(ACK)和同步序列號(SYN)標(biāo)志位的數(shù)據(jù)段響應(yīng)主機A，也告訴主機A兩件事：我已經(jīng)收到你的請求了，你可以傳輸數(shù)據(jù)了；你要用那個序列號作為起始數(shù)據(jù)段來回應(yīng)我。

3.主機A收到這個數(shù)據(jù)段后，再發(fā)送一個確認(rèn)應(yīng)答，確認(rèn)已收到主機B 的數(shù)據(jù)段：“我已收到回復(fù),我現(xiàn)在要開始傳輸實際數(shù)據(jù)了”。這樣3次握手就完成了,主機A和主機B就可以傳輸數(shù)據(jù)了。

六、Post和Get的區(qū)別？

1. 一般發(fā)送Get請求向服務(wù)器索取數(shù)據(jù)，發(fā)送Post請求向服務(wù)器提交數(shù)據(jù)。
2. get是把參數(shù)數(shù)據(jù)隊列加到提交表單的ACTION屬性所指的URL中，值和表單內(nèi)各個字段一一對應(yīng)，在URL中可以看 到。post是通過HTTP post機制，將表單內(nèi)各個字段與其內(nèi)容放置在HTML HEADER內(nèi)一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3. 對于get方式，服務(wù)器端用Request.QueryString獲取變量的值，對于post方式，服務(wù)器端用Request.Form獲取提交的數(shù)據(jù)。
4. get傳送的數(shù)據(jù)量較小，不能大于2KB。post傳送的數(shù)據(jù)量較大，一般被默認(rèn)為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。
5. get安全性非常低，post安全性較高。但是執(zhí)行效率卻比Post方法好。

建議：
1）get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數(shù)據(jù)提交方式；
2）在做數(shù)據(jù)查詢時，建議用Get方式；而在做數(shù)據(jù)添加、修改或刪除時，建議用Post方式；

七、請求頭和響應(yīng)頭部分字段的含義：

• Host：指定服務(wù)器域名，可用來區(qū)分訪問一個服務(wù)器上的不同服務(wù)
• Connection：keep-alive表示要求服務(wù)器不要關(guān)閉TCP連接，close表示明確要求關(guān)閉連接，默認(rèn)值是keep-alive
• Accept-Encoding：說明自己可以接收的壓縮方式
• User-Agent：用戶代理，是服務(wù)器能識別客戶端的操作系統(tǒng)（Android、IOS、WEB）及相關(guān)的信息。作用是幫助服務(wù)器區(qū)分客戶端，并且針對不同客戶端讓用戶看到不同數(shù)據(jù)，做不同操作。
• Content-Type：服務(wù)器告訴客戶端數(shù)據(jù)的格式，常見的值有text/plain，image/jpeg，image/png，video/mp4，application/json，application/zip。這些數(shù)據(jù)類型總稱為MIME TYPE。
• Content-Encoding：服務(wù)器數(shù)據(jù)壓縮方式
• Transfer-Encoding：chunked表示采用分塊傳輸編碼，有該字段則無需使用Content-Length字段。
• Content-Length：聲明數(shù)據(jù)的長度，請求和回應(yīng)頭部都可以使用該字段。

八、其他相關(guān)文章

HTTP 必知必會的那些
TCP/IP、Socket 和協(xié)議設(shè)計
Http協(xié)議與TCP協(xié)議簡單理解