1. HTTP協(xié)議

1.1、HTTP報文結構

HTTP請求報文

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

 

 

HTTP響應報文

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

 

 

1.2、常見(jiàn)header

Host, 請求頭

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

Accept-Language，請求頭，支持語(yǔ)言，客戶(hù)端瀏覽器的設置，如：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ù)器或客戶(hù)端在上次設置的COOKIE，包括作用域名(.360buy.com)，過(guò)期時(shí)間，鍵與值。

Content-Type, 響應的數據類(lèi)型：text/html;charset=gbk

Content-Length，響應的數據體大小

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

1.3、URL內容

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

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

格式說(shuō)明：

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

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

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

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

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

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

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

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

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

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

1.4、KeepAlive參數

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

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

1.5、狀態(tài)碼

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

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

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

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

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

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

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

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

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

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

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

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

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

1.6、HTTP1.0/1.1/2.0 的區別

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

HTTP 1.0

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

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

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

HTTP 1.0 只使用 header 中的 If-Modified-Since 和 Expires 作為緩存失效的標準。

HTTP 1.0 不支持斷點(diǎn)續傳，也就是說(shuō)，每次都會(huì )傳送全部的頁(yè)面和數據。

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

HTTP 1.1

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

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

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

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

HTTP 1.1 支持斷點(diǎn)續傳，通過(guò)使用請求頭中的 Range 來(lái)實(shí)現。

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

HTTP 2.0

HTTP 2.0 是 2015 年開(kāi)發(fā)出來(lái)的標準，它主要做的改變如下

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

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

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

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

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

2.1、通信模型

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

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

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

2.2、通信方式

TCP通信

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

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

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

HTTP協(xié)議通信

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

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

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

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

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

3. HTTPS加密

3.1、加密過(guò)程

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

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

生成隨機值

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

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

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

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

將加密的內容發(fā)送給客戶(hù)端

3.2、中間人攻擊

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

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

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

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

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

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

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

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

3.3、CA證書(shū)

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

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

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

代碼簽名證書(shū)，用于簽名二進(jìn)制文件，比如Windows內核驅動(dòng)，Firefox插件，Java代碼簽名等等。

客戶(hù)端證書(shū)，用于加密郵件。

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

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

3.4、數字簽名

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

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

CA擁有非對稱(chēng)加密的私鑰和公鑰。

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

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

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

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

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

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

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

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

4. Session、Cookie & Token

4.1、cookie

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

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

4.2、session

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

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

cookie與session區別

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

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

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

4.3、Token

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

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

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

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

session與token區別

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

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

token提供認證和授權功能，作為身份認證，token安全性比session好;

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

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

5.1、socket套接字

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

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

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

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

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

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

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

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

5.3、套接字(socket)函數

服務(wù)端

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

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

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

客戶(hù)端

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

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

公共用途

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

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

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

s.recvfrom() 接收UDP數據

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

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

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

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

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

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

面向鎖的套接字方法

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

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

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

面向文件的套接字的函數

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

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

末

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

– END –