1. HTTP協(xié)議

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

HTTP請(qǐng)求報(bào)文

一個(gè)HTTP請(qǐng)求報(bào)文由請(qǐng)求行(request line)、請(qǐng)求頭部(header)、空行和請(qǐng)求數(shù)據(jù)4個(gè)部分組成

 

 

HTTP響應(yīng)報(bào)文

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

 

 

1.2、常見header

Host, 請(qǐng)求頭

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

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

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

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

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由三部分組成：資源類型、存放資源的主機(jī)域名、資源文件名，URL的一般語(yǔ)法格式為：(帶方括號(hào)[]的為可選項(xiàng))：

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

格式說(shuō)明：

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

ftp 通過(guò) FTP訪問(wèn)資源。格式 ftp://

http 通過(guò) HTTP 訪問(wèn)該資源。 格式 http://

https 通過(guò)安全的 HTTPS 訪問(wèn)該資源。 格式 https://

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

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

path(路徑)：由零或多個(gè)“/”符號(hào)隔開的字符串，一般用來(lái)表示主機(jī)上的一個(gè)目錄或文件地址。

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

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

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

1.4、KeepAlive參數(shù)

KeepAlive值是個(gè)布爾值，有兩個(gè)值On和Off，簡(jiǎn)單來(lái)說(shuō)，當(dāng)值為On的時(shí)候，用戶發(fā)起HTTP請(qǐng)求后，Apache不會(huì)立刻關(guān)閉這個(gè)連接，當(dāng)還有用戶發(fā)起HTTP請(qǐng)求時(shí)，還會(huì)使用這個(gè)連接，

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

1.5、狀態(tài)碼

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTP 1.0

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

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

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

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

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

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

HTTP 1.1

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

HTTP 1.1 使用了摘要算法來(lái)進(jìn)行身份驗(yàn)證

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

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

HTTP 1.1 支持?jǐn)帱c(diǎn)續(xù)傳，通過(guò)使用請(qǐng)求頭中的 Range 來(lái)實(shí)現(xiàn)。

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

HTTP 2.0

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

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

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

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

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

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)的客戶端才能實(shí)現(xiàn)通信。目前大多數(shù)APP都是這種模式，如QQ、微博等。

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

2.2、通信方式

TCP通信

這種通信方式是實(shí)現(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ā)送方和接收方之間的兩個(gè)端口必須建立連接，以便在TCP協(xié)議的基礎(chǔ)上進(jìn)行通信。在程序中，端口之間建立連接一般使用Socket(套接字)方法。

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

HTTP協(xié)議通信

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

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

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

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

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

3. HTTPS加密

3.1、加密過(guò)程

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

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

生成隨機(jī)值

用 公鑰加密 隨機(jī)值生成密鑰

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

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

將信息和隨機(jī)值混合在一起 進(jìn)行對(duì)稱加密

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

3.2、中間人攻擊

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

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

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

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

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

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

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

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

3.3、CA證書

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

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

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

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

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

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

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

3.4、數(shù)字簽名

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

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

CA擁有非對(duì)稱加密的私鑰和公鑰。

CA對(duì)證書明文信息進(jìn)行hash。

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

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

瀏覽器驗(yàn)證過(guò)程：

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

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

用證書里說(shuō)明的hash算法對(duì)明文T進(jìn)行hash得到T’。

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

4. Session、Cookie & Token

4.1、cookie

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

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

4.2、session

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

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

cookie與session區(qū)別

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

存儲(chǔ)空間：?jiǎn)蝹€(gè)cookie保存的數(shù)據(jù)不能超過(guò)4K，**很多瀏覽器都限制一個(gè)站點(diǎn)最多保存20個(gè)cookie，**session無(wú)此限制

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

4.3、Token

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

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

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

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

session與token區(qū)別

session機(jī)制存在服務(wù)器壓力增大，CSRF跨站偽造請(qǐng)求攻擊，擴(kuò)展性不強(qiáng)等問(wèn)題;

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

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

session這種會(huì)話存儲(chǔ)方式方式只適用于客戶端代碼和服務(wù)端代碼運(yùn)行在同一臺(tái)服務(wù)器上，token適用于項(xiàng)目級(jí)的前后端分離(前后端代碼運(yùn)行在不同的服務(wù)器下)

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

5.1、socket套接字

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

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

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

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

5.2、套接字的連接過(guò)程

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

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

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

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

服務(wù)端

s.bind() 綁定(主機(jī)，端口號(hào))到套接字

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

s.accept() 被動(dòng)接受TCP客戶的連接，(阻塞式)等待連接到來(lái)(阻塞：無(wú)響應(yīng)直到接受到連接請(qǐng)求)

客戶端

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

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

公共用途

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

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

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

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

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

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

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

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

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

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

面向鎖的套接字方法

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

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

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

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

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

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

末

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

– END –