1. HTTP協(xié)議

1.1、HTTP報文結(jié)構(gòu)

HTTP請求報文

一個HTTP請求報文由請求行(request line)、請求頭部(header)、空行和請求數(shù)據(jù)4個部分組成

 

 

HTTP響應(yīng)報文

HTTP響應(yīng)也由三個部分組成，分別是：狀態(tài)行、消息報頭、響應(yīng)正文。

 

 

1.2、常見header

Host, 請求頭

Accept-Encoding，請求頭，可接受的文本壓縮算法，如： gzip, deflate

Accept-Language，請求頭，支持語言，客戶端瀏覽器的設(shè)置，如：zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3

User-Agent，請求頭，瀏覽器信息，如：Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20100101

Cookie，請求頭，服務(wù)器或客戶端在上次設(shè)置的COOKIE，包括作用域名(.360buy.com)，過期時間，鍵與值。

Content-Type, 響應(yīng)的數(shù)據(jù)類型：text/html;charset=gbk

Content-Length，響應(yīng)的數(shù)據(jù)體大小

Content-Encoding, 如果為文本、HTML信息，則使用的編碼方式

1.3、URL內(nèi)容

URL(Uniform Resource Locator，統(tǒng)一資源定位符)，URL由三部分組成：資源類型、存放資源的主機域名、資源文件名，URL的一般語法格式為：(帶方括號[]的為可選項)：

protocol://hostname[:port]/path/[;parameters][?query]#fragment

格式說明：

protocol(協(xié)議)：指定使用的傳輸協(xié)議， 最常用的是HTTP協(xié)議，它也是目前WWW中應(yīng)用最廣的協(xié)議。

ftp 通過 FTP訪問資源。格式 ftp://

http 通過 HTTP 訪問該資源。 格式 http://

https 通過安全的 HTTPS 訪問該資源。 格式 https://

hostname(主機名)：是指存放資源的服務(wù)器的域名系統(tǒng) (DNS) 主機名或 IP 地址。

:port(端口號)：整數(shù)，可選，省略時使用方案的默認(rèn)端口，各種傳輸協(xié)議都有默認(rèn)的端口號，如http的默認(rèn)端口為80。如果輸入時省略，則使用默認(rèn)端口號。有時候出于安全或其他考慮，可以在服務(wù)器上對端口進行重定義，即采用非標(biāo)準(zhǔn)端口號，此時，URL中就不能省略端口號這一項。

path(路徑)：由零或多個“/”符號隔開的字符串，一般用來表示主機上的一個目錄或文件地址。

;parameters(參數(shù))：這是用于指定特殊參數(shù)的可選項。

?query(查詢)：可選，用于給動態(tài)網(wǎng)頁(如使用CGI、ISAPI、PHP/JSP/ASP/ASP.NET等技術(shù)制作的網(wǎng)頁)傳遞參數(shù)，可有多個參數(shù)，用“&”符號隔開，每個參數(shù)的名和值用“=”符號隔開。

fragment(信息片斷)：字符串，用于指定網(wǎng)絡(luò)資源中的片斷。例如一個網(wǎng)頁中有多個名詞解釋，可使用fragment直接定位到某一名詞解釋。

1.4、KeepAlive參數(shù)

KeepAlive值是個布爾值，有兩個值On和Off，簡單來說，當(dāng)值為On的時候，用戶發(fā)起HTTP請求后，Apache不會立刻關(guān)閉這個連接，當(dāng)還有用戶發(fā)起HTTP請求時，還會使用這個連接，

什么時候關(guān)閉呢?看KeepAliveTimeout這個值，當(dāng)時間達到KeepAliveTimeout這個值的時候才會關(guān)閉連接。當(dāng)值為Off的時候，用戶發(fā)起HTTP請求后，Apache會立刻關(guān)閉這個連接，缺點就是每次訪問都要執(zhí)行一次TCP握手，增加了CPU的開銷。

1.5、狀態(tài)碼

狀態(tài)碼200表示服務(wù)器響應(yīng)成功，服務(wù)器找到了客戶端請求的內(nèi)容，并將內(nèi)容發(fā)送給了客戶端。

狀態(tài)碼302表示臨時跳轉(zhuǎn)。

狀態(tài)碼301代表的是永久性的重定向。

304狀態(tài)碼，被請求的資源內(nèi)容沒有發(fā)生更改。

401 (未授權(quán)) 請求要求身份驗證。 對于需要登錄的網(wǎng)頁，服務(wù)器可能返回此響應(yīng)。

403 (禁止) 服務(wù)器拒絕請求。

404 (未找到) 服務(wù)器找不到請求的網(wǎng)頁。

500 (服務(wù)器內(nèi)部錯誤) 服務(wù)器遇到錯誤，無法完成請求。

501 (尚未實施) 服務(wù)器不具備完成請求的功能。 例如，服務(wù)器無法識別請求方法時可能會返回此代碼。

502 (錯誤網(wǎng)關(guān)) 服務(wù)器作為網(wǎng)關(guān)或代理，從上游服務(wù)器收到無效響應(yīng)。

503 (服務(wù)不可用) 服務(wù)器目前無法使用(由于超載或停機維護)。 通常，這只是暫時狀態(tài)。

504 (網(wǎng)關(guān)超時) 服務(wù)器作為網(wǎng)關(guān)或代理，但是沒有及時從上游服務(wù)器收到請求。

505 (HTTP 版本不受支持) 服務(wù)器不支持請求中所用的 HTTP 協(xié)議版本。

1.6、HTTP1.0/1.1/2.0 的區(qū)別

HTTP1.0最早在網(wǎng)頁中使用是在1996年，那個時候只是使用一些較為簡單的網(wǎng)頁上和網(wǎng)絡(luò)請求上，而HTTP1.1則在1999年才開始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)絡(luò)請求中，同時HTTP1.1也是當(dāng)前使用最為廣泛的HTTP協(xié)議

HTTP 1.0

HTTP 1.0 是在 1996 年引入的，從那時開始，它的普及率就達到了驚人的效果。

HTTP 1.0 僅僅提供了最基本的認(rèn)證，這時候用戶名和密碼還未經(jīng)加密，因此很容易收到窺探。

HTTP 1.0 被設(shè)計用來使用短鏈接，即每次發(fā)送數(shù)據(jù)都會經(jīng)過 TCP 的三次握手和四次揮手，效率比較低。

HTTP 1.0 只使用 header 中的 If-Modified-Since 和 Expires 作為緩存失效的標(biāo)準(zhǔn)。

HTTP 1.0 不支持?jǐn)帱c續(xù)傳，也就是說，每次都會傳送全部的頁面和數(shù)據(jù)。

HTTP 1.0 認(rèn)為每臺計算機只能綁定一個 IP，所以請求消息中的 URL 并沒有傳遞主機名(hostname)。

HTTP 1.1

HTTP 1.1 是 HTTP 1.0 開發(fā)三年后出現(xiàn)的，也就是 1999 年，它做出了以下方面的變化

HTTP 1.1 使用了摘要算法來進行身份驗證

HTTP 1.1 默認(rèn)使用長連接，長連接就是只需一次建立就可以傳輸多次數(shù)據(jù)，傳輸完成后，只需要一次切斷連接即可。長連接的連接時長可以通過請求頭中的 keep-alive 來設(shè)置

HTTP 1.1 中新增加了 E-tag，If-Unmodified-Since, If-Match, If-None-Match 等緩存控制標(biāo)頭來控制緩存失效。

HTTP 1.1 支持?jǐn)帱c續(xù)傳，通過使用請求頭中的 Range 來實現(xiàn)。

HTTP 1.1 使用了虛擬網(wǎng)絡(luò)，在一臺物理服務(wù)器上可以存在多個虛擬主機(Multi-homed Web Servers)，并且它們共享一個IP地址。

HTTP 2.0

HTTP 2.0 是 2015 年開發(fā)出來的標(biāo)準(zhǔn)，它主要做的改變?nèi)缦?/p>

頭部壓縮，由于 HTTP 1.1 經(jīng)常會出現(xiàn) User-Agent、Cookie、Accept、Server、Range 等字段可能會占用幾百甚至幾千字節(jié)，而 Body 卻經(jīng)常只有幾十字節(jié)，所以導(dǎo)致頭部偏重。HTTP 2.0 使用 HPACK 算法進行壓縮。

二進制格式，HTTP 2.0 使用了更加靠近 TCP/IP 的二進制格式，而拋棄了 ASCII 碼，提升了解析效率

強化安全，由于安全已經(jīng)成為重中之重，所以 HTTP2.0 一般都跑在 HTTPS 上。

多路復(fù)用，即每一個請求都是是用作連接共享。一個請求對應(yīng)一個id，這樣一個連接上可以有多個請求。

2. 客戶端與服務(wù)器通信

2.1、通信模型

目前主流的網(wǎng)絡(luò)通信模型有以下兩種：

客戶/服務(wù)器結(jié)構(gòu)(Client/Server，縮寫為C/S，胖客戶)：典型的C/S結(jié)構(gòu)網(wǎng)絡(luò)系統(tǒng)需要相應(yīng)的客戶端才能實現(xiàn)通信。目前大多數(shù)APP都是這種模式，如QQ、微博等。

瀏覽器/服務(wù)器結(jié)構(gòu)(Browser/Server，縮寫為B/S，瘦客戶)：典型的B/S結(jié)構(gòu)網(wǎng)絡(luò)系統(tǒng)只要通過瀏覽器即可訪問，不需要在客戶端機安裝特定的軟件。

2.2、通信方式

TCP通信

這種通信方式是實現(xiàn)C/S模式應(yīng)用程序的主要方式。TCP是可靠的連接通信技術(shù)，主要使用套接字(Socket)。 Socket是TCP/IP協(xié)議中的傳輸層接口。TCP通信是使用TCP/IP協(xié)議、建立在穩(wěn)定連接基礎(chǔ)上的、以流傳輸數(shù)據(jù)的通信方式。

TCP(Transfer Control Protocol)協(xié)議是一種面向連接的、提供可靠傳輸?shù)膮f(xié)議。它可以確保接收方完全正確地接收到發(fā)送方所發(fā)送的全部數(shù)據(jù)。發(fā)送方和接收方之間的兩個端口必須建立連接，以便在TCP協(xié)議的基礎(chǔ)上進行通信。在程序中，端口之間建立連接一般使用Socket(套接字)方法。

當(dāng)服務(wù)器的Socket等待服務(wù)器請求(即等待建立連接)時，客戶機的Socket可以要求進行連接，一旦這兩個Socket連接成功，它們就可以進行雙向數(shù)據(jù)傳輸。TCP協(xié)議為實現(xiàn)可靠的數(shù)據(jù)傳輸提供了一個點對點的通道。

HTTP協(xié)議通信

這種通信方式實現(xiàn)B/S模式應(yīng)用程序的主要方式。HTTP協(xié)議簡稱超文本傳輸協(xié)議，它是應(yīng)用層協(xié)議，主要解決如何包裝數(shù)據(jù)，它建立在TCP/IP協(xié)議之上的一種應(yīng)用，它是一種通用的、無狀態(tài)的、面向?qū)ο蟮膮f(xié)議。 HTTP協(xié)議的作用原理包括四個步驟：

連接：Web瀏覽器與Web服務(wù)器建立連接。

請求：Web瀏覽器通過socket向Web服務(wù)器提交請求。HTTP的請求一般是GET或POST命令(POST用于FORM參數(shù)的傳遞)。

應(yīng)答：Web瀏覽器提交請求后，通過HTTP協(xié)議傳送給Web服務(wù)器。Web服務(wù)器接到后，進行事務(wù)處理，處理結(jié)果又通過HTTP傳回給Web瀏覽器，從而在Web瀏覽器上顯示出所請求的頁面。

關(guān)閉連接：當(dāng)應(yīng)答結(jié)束后，Web瀏覽器與Web服務(wù)器必須斷開，以保證其它Web瀏覽器能夠與Web服務(wù)器建立連接。

3. HTTPS加密

3.1、加密過程

客戶端請求服務(wù)器獲取 證書公鑰

客戶端(SSL/TLS)解析證書(無效會彈出警告)

生成隨機值

用 公鑰加密 隨機值生成密鑰

客戶端將 秘鑰 發(fā)送給服務(wù)器

服務(wù)端用 私鑰 解密 秘鑰 得到隨機值

將信息和隨機值混合在一起 進行對稱加密

將加密的內(nèi)容發(fā)送給客戶端

3.2、中間人攻擊

中間人的確無法得到瀏覽器生成的密鑰B，這個密鑰本身被公鑰A加密了，只有服務(wù)器才有私鑰A’解開拿到它呀!然而中間人卻完全不需要拿到密鑰A’就能干壞事了。請看：

某網(wǎng)站擁有用于非對稱加密的公鑰A、私鑰A’。

瀏覽器向網(wǎng)站服務(wù)器請求，服務(wù)器把公鑰A明文給傳輸瀏覽器。

中間人劫持到公鑰A，保存下來，把數(shù)據(jù)包中的公鑰A替換成自己偽造的公鑰B(它當(dāng)然也擁有公鑰B對應(yīng)的私鑰B’)。

瀏覽器隨機生成一個用于對稱加密的密鑰X，用公鑰B(瀏覽器不知道公鑰被替換了)加密后傳給服務(wù)器。

中間人劫持后用私鑰B’解密得到密鑰X，再用公鑰A加密后傳給服務(wù)器。

服務(wù)器拿到后用私鑰A’解密得到密鑰X。

這樣在雙方都不會發(fā)現(xiàn)異常的情況下，中間人得到了密鑰B。根本原因是瀏覽器無法確認(rèn)自己收到的公鑰是不是網(wǎng)站自己的

3.3、CA證書

CA證書是由CA(Certification Authority)認(rèn)證機構(gòu)發(fā)布的數(shù)字證書。其內(nèi)容包含：電子簽證機關(guān)的信息、公鑰用戶信息、公鑰、簽名和有效期。這里的公鑰服務(wù)端的公鑰，這里的簽名是指：用hash散列函數(shù)計算公開的明文信息的信息摘要，然后采用CA的私鑰對信息摘要進行加密，加密完的密文就是簽名。 即：證書 = 公鑰 + 簽名 +申請者和頒發(fā)者的信息。 客戶端中因為在操作系統(tǒng)中就預(yù)置了CA的公鑰，所以支持解密簽名(因為簽名使用CA的私鑰加密的)

SSL證書是CA證書的一種，CA是負責(zé)簽發(fā)證書、認(rèn)證證書、管理已頒發(fā)證書的機關(guān)。 它制定政策和具體步驟來驗證、識別用戶身份，并對用戶證書進行簽名，以確保證書持有者的身份和公鑰的擁有權(quán)。 SSL證書(http://ssl.idcspy.net/)就是CA機構(gòu)簽發(fā)的。 一般的CA證書，可以直接在WINDOWS上生成。

SSL證書，用于加密HTTP協(xié)議，也就是HTTPS。

代碼簽名證書，用于簽名二進制文件，比如Windows內(nèi)核驅(qū)動，F(xiàn)irefox插件，Java代碼簽名等等。

客戶端證書，用于加密郵件。

雙因素證書，網(wǎng)銀專業(yè)版使用的USB Key里面用的就是這種類型的證書。

網(wǎng)站在使用HTTPS前，需要向“CA機構(gòu)”申請頒發(fā)一份數(shù)字證書，數(shù)字證書里有證書持有者、證書持有者的公鑰等信息，服務(wù)器把證書傳輸給瀏覽器，瀏覽器從證書里取公鑰就行了，證書就如身份證一樣，可以證明“該公鑰對應(yīng)該網(wǎng)站”。然而這里又有一個顯而易見的問題了，證書本身的傳輸過程中，如何防止被篡改?即如何證明證書本身的真實性?身份證有一些防偽技術(shù)，數(shù)字證書怎么防偽呢?

3.4、數(shù)字簽名

我們把證書內(nèi)容生成一份“簽名”，比對證書內(nèi)容和簽名是否一致就能察覺是否被篡改。這種技術(shù)就叫數(shù)字簽名。

數(shù)字簽名制作過程：

CA擁有非對稱加密的私鑰和公鑰。

CA對證書明文信息進行hash。

對hash后的值用私鑰加密，得到數(shù)字簽名。

明文和數(shù)字簽名共同組成了數(shù)字證書，這樣一份數(shù)字證書就可以頒發(fā)給網(wǎng)站了。那瀏覽器拿到服務(wù)器傳來的數(shù)字證書后，如何驗證它是不是真的?(有沒有被篡改、掉包)

瀏覽器驗證過程：

拿到證書，得到明文T，數(shù)字簽名S。

用CA機構(gòu)的公鑰對S解密(由于是瀏覽器信任的機構(gòu)，所以瀏覽器保有它的公鑰。詳情見下文)，得到S’。

用證書里說明的hash算法對明文T進行hash得到T’。

比較S’是否等于T’，等于則表明證書可信。

4. Session、Cookie & Token

4.1、cookie

HTTP協(xié)議本身是無狀態(tài)的。什么是無狀態(tài)呢，即服務(wù)器無法判斷用戶身份。

**cookie是由Web服務(wù)器保存在用戶瀏覽器上的小文件(key-value格式)，包含用戶相關(guān)的信息。**客戶端向服務(wù)器發(fā)起請求，如果服務(wù)器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個Cookie?？蛻舳藶g覽器會把Cookie保存起來。當(dāng)瀏覽器再請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務(wù)器。服務(wù)器檢查該Cookie，以此來辨認(rèn)用戶身份。

4.2、session

session是依賴Cookie實現(xiàn)的。session是服務(wù)器端對象session 是瀏覽器和服務(wù)器會話過程中，服務(wù)器分配的一塊儲存空間。服務(wù)器默認(rèn)為瀏覽器在cookie中設(shè)置 sessionid，瀏覽器在向服務(wù)器請求過程中傳輸 cookie 包含 sessionid ，服務(wù)器根據(jù) sessionid 獲取出會話中存儲的信息，然后確定會話的身份信息。

典型的場景是購物車，當(dāng)你要添加商品到購物車的時候，系統(tǒng)不知道是哪個用戶操作的，因為 HTTP 協(xié)議是無狀態(tài)的。服務(wù)端給特定的用戶創(chuàng)建特定的 Session 之后就可以標(biāo)識這個用戶并且跟蹤這個用戶了。

cookie與session區(qū)別

存儲位置與安全性：cookie數(shù)據(jù)存放在客戶端上，安全性較差，session數(shù)據(jù)放在服務(wù)器上，安全性相對更高;

存儲空間：單個cookie保存的數(shù)據(jù)不能超過4K，**很多瀏覽器都限制一個站點最多保存20個cookie，**session無此限制

占用服務(wù)器資源：session一定時間內(nèi)保存在服務(wù)器上，當(dāng)訪問增多，占用服務(wù)器性能，考慮到服務(wù)器性能方面，應(yīng)當(dāng)使用cookie。

4.3、Token

Token的引入：Token是在客戶端頻繁向服務(wù)端請求數(shù)據(jù)，服務(wù)端頻繁的去數(shù)據(jù)庫查詢用戶名和密碼并進行對比，判斷用戶名和密碼正確與否，并作出相應(yīng)提示，在這樣的背景下，Token便應(yīng)運而生。

Token的定義：Token是服務(wù)端生成的一串字符串，以作客戶端進行請求的一個令牌，當(dāng)?shù)谝淮蔚卿浐?，服?wù)器生成一個Token便將此Token返回給客戶端，以后客戶端只需帶上這個Token前來請求數(shù)據(jù)即可，無需再次帶上用戶名和密碼。

使用Token的目的：Token的目的是為了減輕服務(wù)器的壓力，減少頻繁的查詢數(shù)據(jù)庫，使服務(wù)器更加健壯。

Token 是在服務(wù)端產(chǎn)生的。如果前端使用用戶名/密碼向服務(wù)端請求認(rèn)證，服務(wù)端認(rèn)證成功，那么在服務(wù)端會返回 Token 給前端。前端可以在每次請求的時候帶上 Token 證明自己的合法地位

session與token區(qū)別

session機制存在服務(wù)器壓力增大，CSRF跨站偽造請求攻擊，擴展性不強等問題;

session存儲在服務(wù)器端，token存儲在客戶端

token提供認(rèn)證和授權(quán)功能，作為身份認(rèn)證，token安全性比session好;

session這種會話存儲方式方式只適用于客戶端代碼和服務(wù)端代碼運行在同一臺服務(wù)器上，token適用于項目級的前后端分離(前后端代碼運行在不同的服務(wù)器下)

5. socket網(wǎng)絡(luò)編程

5.1、socket套接字

Socket的英文原義是“孔”或“插座”。作為BSD UNIX的進程通信機制，取后一種意思。通常也稱作”套接字”，用于描述IP地址和端口，是一個通信鏈的句柄，可以用來實現(xiàn)不同虛擬機或不同計算機之間的通信。

將傳輸層及以下的網(wǎng)絡(luò)協(xié)議封裝，提供簡單使用的接口(API)給應(yīng)用層的軟件，專門面向C/S架構(gòu)模型設(shè)計的

三元組：IP地址、協(xié)議、端口號

網(wǎng)絡(luò)層的“ip地址”可以唯一標(biāo)識網(wǎng)絡(luò)中的主機，而傳輸層的“協(xié)議+端口”可以唯一標(biāo)識主機中的應(yīng)用程序(進程)。這樣利用三元組(ip地址，協(xié)議，端口)就可以標(biāo)識網(wǎng)絡(luò)的進程了，網(wǎng)絡(luò)中的進程通信就可以利用這個標(biāo)志與其它進程進行交互。

5.2、套接字的連接過程

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

客戶端請求：指由客戶端的套接字提出請求，目標(biāo)是服務(wù)器端的套接字，需要指出服務(wù)器端套接字的地址和端口號

連接確認(rèn)：當(dāng)服務(wù)器端套接字監(jiān)聽到客戶端套接字的連接請求，就響應(yīng)請求建立一個新的進程，并返回客戶端服務(wù)器的套接字描述，當(dāng)客戶端確認(rèn)描述，連接就正式建立，服務(wù)器端繼續(xù)處于監(jiān)聽狀態(tài)

5.3、套接字(socket)函數(shù)

服務(wù)端

s.bind() 綁定(主機，端口號)到套接字

s.listen() 開始TCP監(jiān)聽必須制定最大連接數(shù)(操作系統(tǒng)同時能夠鏈接的最大數(shù)目)

s.accept() 被動接受TCP客戶的連接，(阻塞式)等待連接到來(阻塞：無響應(yīng)直到接受到連接請求)

客戶端

s.connect() 主動初始化TCP服務(wù)器連接

s.connec_ex() connect()函數(shù)的擴展版本，出錯時返回出錯碼，不拋出異常

公共用途

s.recv() 接收TCP數(shù)據(jù)不可接收’空’

s.send() 發(fā)送TCP數(shù)據(jù)待發(fā)送數(shù)量大于己端緩存剩余區(qū)空間時，數(shù)據(jù)丟失，不會發(fā)完

s.sendall() 發(fā)送完整的TCP數(shù)據(jù)，循環(huán)調(diào)用s.send通常給數(shù)據(jù)加上報頭將數(shù)據(jù)打包更安全可靠，不常用sendall

s.recvfrom() 接收UDP數(shù)據(jù)

s.sendto() 發(fā)送UDP數(shù)據(jù)

s.getpeername() 連接到當(dāng)前套接字的遠端的地址

s.getsockname() 當(dāng)前套接字的地址

s.getsockopt() 返回指定套接字的參數(shù)

s.setsockopt() 設(shè)置指定套接字的參數(shù)

s.close() 關(guān)閉套接字

面向鎖的套接字方法

s.setblocking() 設(shè)置套接字的阻塞與非阻塞模式

s.settimeout() 設(shè)置阻塞套接字操作的超時時間

s.gettimeout() 得到阻塞套接字操作的超時時間

面向文件的套接字的函數(shù)

s.fileno() 套接字的文件描述符

s.makefile() 創(chuàng)建一個與該套接字相關(guān)的文件

末

【面試系列】文章會持續(xù)更新，歡迎關(guān)注公眾號“任冬學(xué)編程”，聽說點贊都能脫單哦!

– END –