導(dǎo)讀在計(jì)算機(jī)網(wǎng)絡(luò)的應(yīng)用層你了解多少，是否知道socket套接字有哪些？知道你的網(wǎng)站為什么訪問慢嗎？知道為什么fidder、Charles能抓到你的包嗎？今天我們....

在計(jì)算機(jī)網(wǎng)絡(luò)的應(yīng)用層你了解多少，是否知道socket套接字有哪些？知道你的網(wǎng)站為什么訪問慢嗎？知道為什么fidder、Charles能抓到你的包嗎？今天我們就來一一揭秘！

一、socket()套接字有哪些？

套接字（socket）是網(wǎng)絡(luò)中不同主機(jī)上的應(yīng)用進(jìn)程進(jìn)行雙向通信的端口的抽象，網(wǎng)絡(luò)進(jìn)程通信的一端就是一個(gè)套接字，不同主機(jī)上的進(jìn)程就是通過套接字發(fā)送數(shù)據(jù)報(bào)來進(jìn)行通信的，如TCP協(xié)議使用主機(jī)的IP地址 端口號來作為TCP連接的端點(diǎn)，這個(gè)端點(diǎn)就是套接字。

套接字主要有以下三種類型：

• 流套接字（SOCK_STREAM）： 流套接字基于TCP傳輸協(xié)議， 主要用于面向連接的、可靠的數(shù)據(jù)傳輸服務(wù)，由于TCP協(xié)議的特點(diǎn)，使用流套接字進(jìn)行通信時(shí)能夠保證數(shù)據(jù)無差錯(cuò)、無重復(fù)傳送、并按順序接收，通信雙方不需要在程序中進(jìn)行相應(yīng)的處理。
• 數(shù)據(jù)報(bào)套接字（SOCK_DGRAM）： 因?yàn)閁DP協(xié)議傳輸?shù)氖菙?shù)據(jù)報(bào)，所以數(shù)據(jù)報(bào)套接字是基于UDP傳輸協(xié)議的，對應(yīng)于無連接的UDP服務(wù)應(yīng)用，該服務(wù)并不能保證數(shù)據(jù)傳輸?shù)目煽啃裕?也無法保證數(shù)據(jù)按照順序到達(dá)， 同時(shí)通信兩端不需要建立長時(shí)間的連接，UDP客戶端發(fā)送一個(gè)數(shù)據(jù)給服務(wù)器后，就可以使用同一個(gè)套接字給另一個(gè)服務(wù)器發(fā)送數(shù)據(jù)， 當(dāng)使用UDP套接字時(shí)，丟包等問題需要在程序中進(jìn)行處理。
• 原始套接字（SOCK_RAW）： 由于流套接字和數(shù)據(jù)報(bào)套接字只能抓取TCP和UDP協(xié)議的數(shù)據(jù)，當(dāng)需要處理非傳輸層數(shù)據(jù)包或操作系統(tǒng)無法處理的數(shù)據(jù)包時(shí)，就需要使用原始套接字來發(fā)送。

二、URI（統(tǒng)一資源標(biāo)識符）和URL（統(tǒng)一資源定位符）之間的區(qū)別？

• URL（統(tǒng)一資源定位符） 也可以說是我們平常上網(wǎng)時(shí)輸入的網(wǎng)址，它標(biāo)識一個(gè)互聯(lián)網(wǎng)資源，并且指定其進(jìn)行操作或獲取該資源的方法，例如CSDN的網(wǎng)址https://blog.csdn.net，該URL標(biāo)識一個(gè)特定資源并表示該資源的某種形式可以通過HTTPS協(xié)議從相應(yīng)的位置獲取。
• URL是URI的子集， 兩者都定義了資源是什么？而URL還定義了如何能夠訪問到資源，URI是一種語義上的抽象概念，可以是絕對的也可以是相對的。而URL則必須提供足夠的信息來定位，是絕對的，

所以總的來說，只要能唯一標(biāo)識資源的就是URI，在URI的基礎(chǔ)上能給出其資源的訪問方式的就是URL。

三、為什么 fidder，charles 能抓到你的包【抓取數(shù)據(jù)包的過程】

假如我們需要抓取客戶端的數(shù)據(jù)包，需要監(jiān)控客戶端與服務(wù)器交互之間的網(wǎng)絡(luò)節(jié)點(diǎn)，監(jiān)控其中任意一個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)（網(wǎng)卡），獲取所有經(jīng)過網(wǎng)卡中的數(shù)據(jù)，對這些數(shù)據(jù)按照網(wǎng)絡(luò)協(xié)議進(jìn)行解析，這就是抓包的基本原理。 而中間的網(wǎng)絡(luò)節(jié)點(diǎn)不受我們控制，是基本無法實(shí)現(xiàn)抓包的，因此只能在客戶端與服務(wù)器之間進(jìn)行抓包。

① 當(dāng)采用抓包工具抓取 HTTP 數(shù)據(jù)包時(shí)，過程如下：

• 首先抓包工具會提出代理服務(wù)，客戶端需要連接該代理；
• 客戶端發(fā)出 HTTP 請求時(shí)，會經(jīng)過抓包工具的代理，抓包工具將請求的原文進(jìn)行展示；
• 抓包工具使用該原文將請求發(fā)送給服務(wù)器；
• 服務(wù)器返回結(jié)果給抓包工具，抓包工具將返回結(jié)果進(jìn)行展示；
• 抓包工具將服務(wù)器返回的結(jié)果原樣返回給客戶端。

這里抓包工具相當(dāng)于透明人，數(shù)據(jù)經(jīng)過的時(shí)候它一只手接到數(shù)據(jù)，然后另一只手把數(shù)據(jù)傳出去。

② 當(dāng)抓取 HTTPS 數(shù)據(jù)包時(shí)：

• 客戶端連接抓包工具提供的代理服務(wù)，并安裝抓包工具的根證書；
• 客戶端發(fā)出 HTTPS 請求，抓包工具模擬服務(wù)器與客戶端進(jìn)行 TLS握手交換密鑰等流程；
• 抓包工具發(fā)送一個(gè) HTTPS 請求給客戶端請求的目標(biāo)服務(wù)器，并與目標(biāo)服務(wù)器進(jìn)行 TLS 握手交換密鑰等流程；
• 客戶端使用與抓包工具協(xié)定好的密鑰加密數(shù)據(jù)后發(fā)送給抓包工具；
• 抓包工具使用與客戶端協(xié)定好的密鑰解密數(shù)據(jù)，并將結(jié)果進(jìn)行展示；
• 抓包工具將解密后的客戶端數(shù)據(jù)，使用與服務(wù)器協(xié)定好的密鑰進(jìn)行加密后發(fā)送給目標(biāo)服務(wù)器；
• 服務(wù)器解密數(shù)據(jù)后，做對應(yīng)的邏輯處理，然后將返回結(jié)果使用與抓包工具協(xié)定好的密鑰進(jìn)行加密發(fā)送給抓包工具；
• 抓包工具將服務(wù)器返回的結(jié)果，用與服務(wù)器協(xié)定好的密鑰解密，并將結(jié)果進(jìn)行展示；
• 抓包工具將解密后的服務(wù)器返回?cái)?shù)據(jù)，使用與客戶端協(xié)定好的密鑰進(jìn)行加密后發(fā)送給客戶端；
• 客戶端解密數(shù)據(jù)。

這個(gè)時(shí)候抓包工具對客戶端來說相當(dāng)于服務(wù)器，對服務(wù)器來說相當(dāng)于客戶端。 在這個(gè)傳輸過程中，客戶端會以為它就是目標(biāo)服務(wù)器，服務(wù)器也會以為它就是請求發(fā)起的客戶端。

四、如果你訪問一個(gè)網(wǎng)站很慢，怎么排查和解決？

網(wǎng)站打開慢的原因有很多，總結(jié)一下最常見的幾個(gè)。

• 查看本地網(wǎng)絡(luò)是否正常，查看網(wǎng)絡(luò)帶寬是否被占用，如有其他進(jìn)程正在占用本地網(wǎng)絡(luò)帶寬。
• 若網(wǎng)絡(luò)連接正常，那么就應(yīng)該對該網(wǎng)站的服務(wù)器速度進(jìn)行排查，通過ping命令查看連接到服務(wù)器的時(shí)間和丟包情況，如果服務(wù)器正常，那么丟包率一般不會超過1%， 其次是ping值要小，最后是ping值要穩(wěn)定，如果ping值的最大和最小差值過大說明路由不穩(wěn)定。 或者我們查看打開同臺服務(wù)器上的其他網(wǎng)站的速度，看打開其他網(wǎng)站的速度是否也慢。
• 如果網(wǎng)站打開速度時(shí)快時(shí)慢，甚至有時(shí)候打不開的情況，那么有可能是空間不穩(wěn)定，如果確定了是該問題，那么就應(yīng)該找你的空間商更換空間了，可以選擇購買雙線或多線空間。
• 從網(wǎng)站本身尋找原因，網(wǎng)站的問題主要包括網(wǎng)站程序設(shè)計(jì)、網(wǎng)頁結(jié)構(gòu)設(shè)計(jì)和網(wǎng)頁內(nèi)容三部分。

1、網(wǎng)站程序設(shè)計(jì)： 當(dāng)訪問網(wǎng)頁中有拖慢網(wǎng)站打開速度的代碼，會直接影響網(wǎng)站的打開速度，如網(wǎng)頁中使用的統(tǒng)計(jì)代碼，一般是要放置在網(wǎng)站末尾的，防止其在加載過程中出現(xiàn)延遲。

2、網(wǎng)頁結(jié)構(gòu)設(shè)計(jì)： 查看網(wǎng)頁布局的代碼，如果網(wǎng)頁使用的table布局的網(wǎng)頁，查看是否被嵌套次數(shù)過多，或者是使用一個(gè)大表格分成多個(gè)小表格的布局，這個(gè)時(shí)候可以使用div配合css來改進(jìn)。

3、網(wǎng)頁內(nèi)容： 查看網(wǎng)頁中是否有許多大尺寸的圖片和大尺寸的flash存在，我們可以通過降低圖片質(zhì)量，減少圖片尺寸，少用過多的flash來解決。或者可能是有的網(wǎng)站引用了其他網(wǎng)站的內(nèi)容， 若某些被引用的網(wǎng)站訪問速度慢或者不存在，該網(wǎng)站的打開速度自然會變慢，所以可以直接減少不必要的加載項(xiàng)。

五、說一下網(wǎng)頁解析的全過程【用戶輸入網(wǎng)址到顯示對應(yīng)頁面的全過程】

在用戶輸入U(xiǎn)RL之后，瀏覽器首先會進(jìn)行DNS解析，將用戶輸入的域名解析成web服務(wù)器的IP地址，之后會通過該IP地址與服務(wù)器進(jìn)行三次握手建立TCP連接，連接完成之后通過HTTP協(xié)議發(fā)送客戶端的請求，在服務(wù)器接收到該請求之后，會根據(jù)該請求體中的內(nèi)容決定如何獲取目標(biāo)文件，并且將目標(biāo)文件返回給客戶端；瀏覽器在收到文件之后，首先會通過解析HTML文件為DOM樹，再解析CSS文件為渲染樹，在CSS文件解析完成之后將根據(jù)渲染樹的布局在頁面上顯示網(wǎng)頁；最后客戶端和服務(wù)器通過四次揮手?jǐn)嚅_連接。

過程如下圖這樣：

其中的名詞解析：

• DNS 解析： 當(dāng)用戶輸入一個(gè)網(wǎng)址并按下回車鍵的時(shí)候，瀏覽器獲得一個(gè)域名，而在實(shí)際通信過程中，我們需要的是一個(gè) IP地址，因此我們需要先把域名轉(zhuǎn)換成相應(yīng) IP 地址。
• TCP 連接： 瀏覽器通過 DNS 獲取到 Web 服務(wù)器真正的 IP 地址后，便向 Web 服務(wù)器發(fā)起 TCP 連接請求，通過 TCP三次握手建立好連接后，瀏覽器便可以將 HTTP 請求數(shù)據(jù)發(fā)送給服務(wù)器了。
• 發(fā)送 HTTP 請求： 瀏覽器向 Web 服務(wù)器發(fā)起一個(gè) HTTP 請求，HTTP 協(xié)議是建立在 TCP 協(xié)議之上的應(yīng)用層協(xié)議，其本質(zhì)是在建立起的TCP連接中，按照HTTP協(xié)議標(biāo)準(zhǔn)發(fā)送一個(gè)索要網(wǎng)頁的請求。

在這一過程中，會涉及到負(fù)載均衡等操作。

拓展：什么是負(fù)載均衡？

負(fù)載均衡， 英文名為 Load Balance，其含義是指將負(fù)載（工作任務(wù)）進(jìn)行平衡、分?jǐn)偟蕉鄠€(gè)操作單元上進(jìn)行運(yùn)行， 例如 FTP 服務(wù)器、Web 服務(wù)器、企業(yè)核心服務(wù)器和其他主要任務(wù)服務(wù)器等，從而協(xié)同完成工作任務(wù)。

負(fù)載均衡建立在現(xiàn)有的網(wǎng)絡(luò)之上，它提供了一種透明且廉價(jià)有效的方法擴(kuò)展服務(wù)器和網(wǎng)絡(luò)設(shè)備的帶寬、增加吞吐量、加強(qiáng)網(wǎng)絡(luò)處理能力并提高網(wǎng)絡(luò)的靈活性和可用性。

負(fù)載均衡是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一， 例如天貓、京東等大型用戶網(wǎng)站中為了處理海量用戶發(fā)起的請求，其往往采用分布式服務(wù)器，并通過引入反向代理等方式將用戶請求均勻分發(fā)到每個(gè)服務(wù)器上，而這一過程所實(shí)現(xiàn)的就是負(fù)載均衡。

• 處理請求并返回： 服務(wù)器獲取到客戶端的 HTTP 請求后，會根據(jù) HTTP 請求中的內(nèi)容來決定如何獲取相應(yīng)的文件，并將文件發(fā)送給瀏覽器。
• 瀏覽器渲染： 瀏覽器根據(jù)響應(yīng)開始顯示頁面，首先解析 HTML 文件構(gòu)建 DOM 樹，然后解析 CSS文件構(gòu)建渲染樹，等到渲染樹構(gòu)建完成后，瀏覽器開始布局渲染樹并將其繪制到屏幕上。
• 斷開連接： 客戶端和服務(wù)器通過四次揮手終止 TCP 連接。

今日總結(jié)

今天的內(nèi)容主要就是學(xué)習(xí)了網(wǎng)站的請求和顯示過程，了解其中通信的原理，URL和URI的區(qū)別、如何解決網(wǎng)站訪問慢等問題。

如果小伙伴們有遇到其他相關(guān)的面試題，歡迎在評論區(qū)留言提出，我會把大家提出的總結(jié)到文章內(nèi), 歡迎小伙伴們一起評論區(qū)打卡學(xué)習(xí)！