抱佛腳一時(shí)爽，一直抱佛腳一直爽爬早！這篇文章總結(jié)常見的計(jì)算機(jī)網(wǎng)絡(luò)面試問題~因?yàn)槭潜Х鹉_碳锈，所以結(jié)構(gòu)上沒有什么邏輯...

參考鏈接：Waking-Up CycNotes 糯剐唬客網(wǎng) 博客園 知乎專欄

session vs cookie

• Cookie通過在客戶端記錄信息確定用戶身份，Session通過在服務(wù)器端記錄信息確定用戶身份

• 通常session的生存期會(huì)比cookie更長一些

• 考慮到安全應(yīng)該使用session：別人可以分析存放在本地的cookie并進(jìn)行cookie欺騙

• 考慮到服務(wù)器性能應(yīng)該使用cookie：session會(huì)在一定時(shí)間內(nèi)保留在服務(wù)器上

• cookie的分類

  • 會(huì)話cookie：關(guān)閉瀏覽器窗口，cookie就消失泽篮；一般不存儲(chǔ)在硬盤上而是保存在內(nèi)存里

  • 持久cookie：把cookie保存到硬盤上坊秸，關(guān)閉后再次打開瀏覽器，這些cookie仍然有效直到超過設(shè)定的過期時(shí)間

• 流程

  • 若沒有禁用cookie

    • 客戶端第一次發(fā)請(qǐng)求給服務(wù)端选脊，請(qǐng)求中有包含用戶名和密碼的表單

    • 服務(wù)端驗(yàn)證用戶名和密碼杭抠，把用戶信息存儲(chǔ)到 Redis 中，它在 Redis 中的 Key 稱為 Session ID恳啥，返回響應(yīng)報(bào)文的 Set-Cookie 首部字段包含了這個(gè) Session ID

    • 客戶端收到響應(yīng)報(bào)文之后將該id寫入 Cookie 偏灿，存入瀏覽器中

    • 客戶端之后對(duì)同一個(gè)服務(wù)器進(jìn)行請(qǐng)求時(shí)會(huì)包含該 Cookie

    • 服務(wù)器收到之后提取出 Session ID，從 Redis 中取出用戶信息钝的，繼續(xù)之前的業(yè)務(wù)操作

  • 若禁用了cookie

    • 客戶端第一次發(fā)請(qǐng)求給服務(wù)端

    • 服務(wù)端創(chuàng)建session并生成sessionId翁垂，返回給客戶端

    • 客戶端再次發(fā)請(qǐng)求，通過url重寫等方法在請(qǐng)求中加上sessionId發(fā)給服務(wù)端

    • 服務(wù)器按照sessionId把這個(gè)session檢索出來使用

token

• 最簡單的token組成:uid(用戶唯一的身份標(biāo)識(shí))硝桩、time(當(dāng)前時(shí)間的時(shí)間戳)沿猜、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成一定長的十六進(jìn)制字符串碗脊，可以防止惡意第三方拼接token請(qǐng)求服務(wù)器)啼肩。還可以把不變的參數(shù)也放進(jìn)token，避免多次查庫

• 當(dāng)用戶首次登錄成功（注冊(cè)也是一種可以適用的場(chǎng)景）之后, 服務(wù)器端就會(huì)生成一個(gè) token 值，這個(gè)值祈坠，會(huì)在服務(wù)器保存token值(保存在數(shù)據(jù)庫中)害碾，再將這個(gè)token值返回給客戶端

• 客戶端拿到 token 值之后,進(jìn)行本地保存；當(dāng)客戶端再次發(fā)送網(wǎng)絡(luò)請(qǐng)求(一般不是登錄請(qǐng)求)的時(shí)候,就會(huì)將這個(gè) token 值附帶到參數(shù)中發(fā)送給服務(wù)器

token vs session vs cookie

• session代表服務(wù)器與瀏覽器的一次會(huì)話過程赦拘，token是一種認(rèn)證手段

• cookie慌随，session都可以是token存儲(chǔ)的一種方式

• 作為身份認(rèn)證，token安全性比session好

socket

含義

• 應(yīng)用層與TCP/IP協(xié)議族通信的中間軟件抽象層

• 把復(fù)雜的TCP/IP協(xié)議族隱藏在Socket接口后面另绩，對(duì)用戶來說儒陨，一組簡單的接口就是全部，讓Socket去組織數(shù)據(jù)笋籽，以符合指定的協(xié)議

套接字地址

• = ip + 端口號(hào)

• 當(dāng)客戶端發(fā)起一個(gè)連接請(qǐng)求時(shí)蹦漠，客戶端套接字地址中的端口是由內(nèi)核自動(dòng)分配的，稱為臨時(shí)端口

• 服務(wù)端的套接字端口通常是某個(gè)知名的端口

• 一個(gè)連接由它兩端的套接字地址唯一確定

套接字接口

• 是一組函數(shù)

socket通信（網(wǎng)絡(luò)I/O）過程

• 圖例（博客園）

• 服務(wù)端

  • 初始化socket（包括協(xié)議车海、socket類型等）

  • 與端口綁定（bind笛园，ip地址+端口號(hào)用于標(biāo)識(shí)socket）

  • 對(duì)端口進(jìn)行監(jiān)聽（listen）

  • 調(diào)用accept（是阻塞的），等待客戶端連接

  • 處理請(qǐng)求

  • close（注意最后一個(gè)close后返回accept階段侍芝，等待下一個(gè)連接請(qǐng)求）

• 客戶端

  • 初始化socket（包括協(xié)議研铆、socket類型等）

  • 發(fā)送連接請(qǐng)求（connect）

  • 發(fā)送數(shù)據(jù)請(qǐng)求

  • 關(guān)閉連接（close）

• 當(dāng)接收到一個(gè)TCP連接請(qǐng)求后，如果上層還沒有接受它州叠，那么系統(tǒng)將緩存這個(gè)連接請(qǐng)求棵红；當(dāng)超過指定數(shù)量后，系統(tǒng)將會(huì)拒絕連接咧栗；假如緩存的TCP連接請(qǐng)求發(fā)送來數(shù)據(jù)逆甜，那么系統(tǒng)也會(huì)緩存這些數(shù)據(jù)，等待SocketServer獲得這個(gè)連接的時(shí)候一并交給它

I/O模型

總過程

對(duì)于一個(gè)套接字上的輸入操作致板，第一步通常涉及等待數(shù)據(jù)從網(wǎng)絡(luò)中到達(dá)交煞。當(dāng)所等待數(shù)據(jù)到達(dá)時(shí)，它被復(fù)制到內(nèi)核中的某個(gè)緩沖區(qū)斟或。第二步就是把數(shù)據(jù)從內(nèi)核緩沖區(qū)復(fù)制到應(yīng)用進(jìn)程緩沖區(qū)

同步 vs 異步

• 同步：用戶進(jìn)程觸發(fā)IO操作素征，須等待或者主動(dòng)的去詢問IO是否完成，完成則發(fā)送IO系統(tǒng)調(diào)用

• 異步：用戶進(jìn)程觸發(fā)IO 操作以后便開始做自己的事情萝挤，而當(dāng)IO 操作已經(jīng)完成的時(shí)候會(huì)得到IO 完成的通知

阻塞 vs 非阻塞

• 阻塞：數(shù)據(jù)未就緒時(shí)讀取或者寫入函數(shù)將一直等待

• 非阻塞：數(shù)據(jù)未就緒時(shí)會(huì)立刻得到error

阻塞式I/O

• 應(yīng)用進(jìn)程被阻塞御毅，直到數(shù)據(jù)從內(nèi)核緩沖區(qū)復(fù)制到應(yīng)用進(jìn)程緩沖區(qū)中才返回

• 其它應(yīng)用進(jìn)程還可以執(zhí)行，所以不消耗 CPU

非阻塞式I/O

• 應(yīng)用進(jìn)程執(zhí)行系統(tǒng)調(diào)用之后怜珍，內(nèi)核返回一個(gè)錯(cuò)誤碼亚享。應(yīng)用進(jìn)程可以繼續(xù)執(zhí)行，但是需要不斷的執(zhí)行系統(tǒng)調(diào)用來獲知 I/O 是否完成绘面，這種方式稱為輪詢（polling）

• CPU 要處理更多的系統(tǒng)調(diào)用欺税，因此這種模型的 CPU 利用率比較低

I/O多路復(fù)用

• 讓單個(gè)進(jìn)程（reactor）具有處理多個(gè) I/O 事件的能力

• 主進(jìn)程是阻塞的

• 使用 select / poll / epoll 等待數(shù)據(jù)侈沪，并且可以等待多個(gè)套接字中的任何一個(gè)變?yōu)榭勺x。這一過程會(huì)被阻塞晚凿，當(dāng)某一個(gè)套接字可讀時(shí)返回亭罪，之后再使用 recvfrom 把數(shù)據(jù)從內(nèi)核復(fù)制到進(jìn)程中

信號(hào)驅(qū)動(dòng) I/O

• 應(yīng)用進(jìn)程使用 sigaction 系統(tǒng)調(diào)用，內(nèi)核立即返回歼秽，應(yīng)用進(jìn)程可以繼續(xù)執(zhí)行应役，也就是說等待數(shù)據(jù)階段應(yīng)用進(jìn)程是非阻塞的

• 內(nèi)核在數(shù)據(jù)到達(dá)時(shí)向應(yīng)用進(jìn)程發(fā)送 SIGIO 信號(hào)，應(yīng)用進(jìn)程收到之后在信號(hào)處理程序中調(diào)用 recvfrom 將數(shù)據(jù)從內(nèi)核復(fù)制到應(yīng)用進(jìn)程中

異步I/O

• 應(yīng)用進(jìn)程執(zhí)行 aio_read 系統(tǒng)調(diào)用會(huì)立即返回燥筷，應(yīng)用進(jìn)程可以繼續(xù)執(zhí)行箩祥，不會(huì)被阻塞，內(nèi)核會(huì)在所有操作完成之后向應(yīng)用進(jìn)程發(fā)送信號(hào)

• 異步 I/O 的信號(hào)是通知應(yīng)用進(jìn)程 I/O 完成肆氓，而信號(hào)驅(qū)動(dòng) I/O 的信號(hào)是通知應(yīng)用進(jìn)程可以開始 I/O

select vs poll vs epoll

select

• 用戶把需要監(jiān)控的描述符對(duì)應(yīng)的bit置為1

• 用戶進(jìn)程調(diào)用select（是一個(gè)系統(tǒng)調(diào)用）袍祖，整個(gè)進(jìn)程會(huì)被阻塞，直到select返回

• select把描述符集從用戶態(tài)拷貝到內(nèi)核態(tài)谢揪，不斷輪詢所負(fù)責(zé)的所有socket蕉陋，當(dāng)任何一個(gè)/多個(gè)socket中的數(shù)據(jù)準(zhǔn)備好了，把它們對(duì)應(yīng)的bit置為0拨扶，并把所有描述符從內(nèi)核態(tài)拷貝回用戶態(tài)凳鬓，select返回

• 用戶進(jìn)程遍歷檢查描述符集中哪個(gè)描述符上返回了，通過系統(tǒng)調(diào)用調(diào)用內(nèi)核的read操作患民，把數(shù)據(jù)從內(nèi)核拷貝到用戶進(jìn)程的地址空間

• 描述符集的大小受限于FD_SIZE

poll

• 本質(zhì)上和select沒有區(qū)別

• 但是它沒有最大連接數(shù)的限制缩举，原因是它是基于鏈表來存儲(chǔ)的

• 每增加一個(gè)描述符就向數(shù)組中加入一個(gè)含描述符的結(jié)構(gòu)體，結(jié)構(gòu)體只需拷貝一次到內(nèi)核態(tài)

epoll

• 只返回狀態(tài)發(fā)生變化的文件描述符給用戶：文件描述符就緒時(shí)匹颤，采用回調(diào)機(jī)制蚁孔，避免了輪詢（回調(diào)函數(shù)將就緒的描述符添加到一個(gè)鏈表中，執(zhí)行epoll_wait時(shí)惋嚎，返回這個(gè)鏈表）

• 當(dāng)連接數(shù)較多并且有很多的不活躍連接時(shí)，epoll的效率比其它兩者高很多站刑；但是當(dāng)連接數(shù)較少并且都十分活躍的情況下另伍，由于epoll需要很多回調(diào)，因此性能可能低于其它兩者

• 水平觸發(fā) vs 邊緣觸發(fā)

  • 水平觸發(fā)（LT绞旅，Level Trigger）模式下摆尝，一個(gè)文件描述符F就緒觸發(fā)通知，如果用戶程序沒有一次性把數(shù)據(jù)讀寫完因悲，下次用戶調(diào)用epoll_wait時(shí)還會(huì)通知用戶F就緒了

  • 邊緣觸發(fā)（ET堕汞，Edge Trigger）模式下，當(dāng)描述符從未就緒變?yōu)榫途w時(shí)通知一次晃琳，之后不會(huì)再通知讯检，直到再次從未就緒變?yōu)榫途w琐鲁；所以邊緣觸發(fā)一定要用非阻塞（non-block）IO

主機(jī)間通信

方式

• 客戶-服務(wù)器（C/S）：客戶是服務(wù)的請(qǐng)求方，服務(wù)器是服務(wù)的提供方

• 對(duì)等（P2P）：不區(qū)分客戶和服務(wù)器

過程

• 若在同一局域網(wǎng)中

  • 若A的ARP緩存中有主機(jī)B的IP到MAC的映射

    • 構(gòu)造報(bào)文：目的IP人灼、MAC都是主機(jī)B围段；源IP、MAC都是主機(jī)A

    • 把報(bào)文發(fā)給交換機(jī)C投放，C記錄A的MAC到端口號(hào)的映射

      • 若C記錄過B的MAC到端口號(hào)的映射：將報(bào)文從對(duì)應(yīng)端口轉(zhuǎn)發(fā)出去

      • 若C未記錄B的MAC到端口號(hào)的映射：洪泛奈泪，廣播報(bào)文到局域網(wǎng)所有機(jī)器；B收到廣播后會(huì)發(fā)給C要回復(fù)給A的報(bào)文灸芳；C記錄B的MAC到端口號(hào)的映射

  • 若A的ARP緩存中沒有主機(jī)B的IP到MAC的映射

    • A發(fā)送ARP請(qǐng)求報(bào)文給C

    • C洪泛涝桅，把ARP請(qǐng)求廣播到局域網(wǎng)所有機(jī)器

    • B收到廣播報(bào)文，在自己的ARP緩存表中寫入A的IP到MAC的映射烙样；將自己的MAC封裝到ARP回復(fù)報(bào)文中冯遂，單播給A

    • A獲取到主機(jī)B的MAC后，在自己的ARP緩存表中寫入B的IP到MAC的映射

• 若不在同一局域網(wǎng)中

  • A先發(fā)給路由器（目的IP是路由器）

電路交換 vs 分組交換

電路交換

建立連接误阻，且在整個(gè)通信過程中始終占用該鏈路

分組交換

• 每個(gè)分組都有首部和尾部债蜜，包含了源地址和目的地址等控制信息

• 在同一條傳輸線路上允許同時(shí)傳輸多個(gè)分組，分組交換不需要占用傳輸線路

傳輸時(shí)延 vs 傳播時(shí)延

傳輸時(shí)延

數(shù)據(jù)幀的長度 / 傳輸速率

傳播時(shí)延

信道長度 / 電磁波傳播速度

體系結(jié)構(gòu)

五層協(xié)議

OSI七層協(xié)議

把應(yīng)用層由上至下分為：

• 會(huì)話層：建立及管理會(huì)話

• 表示層：數(shù)據(jù)壓縮精耐、加密以及數(shù)據(jù)描述狼速，這使得應(yīng)用程序不必關(guān)心在各臺(tái)主機(jī)中數(shù)據(jù)內(nèi)部格式不同的問題

• 應(yīng)用層

TCP/IP四層協(xié)議

• 把數(shù)據(jù)鏈路層和物理層合為網(wǎng)絡(luò)接口層

• TCP/IP 體系結(jié)構(gòu)不嚴(yán)格遵循 OSI 分層概念，應(yīng)用層可能會(huì)直接使用 IP 層或者網(wǎng)絡(luò)接口層

數(shù)據(jù)在各層之間的傳遞過程

• 在向下的過程中卦停，需要添加下層協(xié)議所需要的首部或者尾部

• 在向上的過程中不斷拆開首部和尾部

路由器 vs 交換機(jī)

路由器

網(wǎng)絡(luò)層設(shè)備向胡，連接不同的局域網(wǎng)，根據(jù)IP地址進(jìn)行轉(zhuǎn)發(fā)

交換機(jī)

鏈路層設(shè)備惊完，連接同一局域網(wǎng)中的不同主機(jī)僵芹，根據(jù)MAC地址進(jìn)行轉(zhuǎn)發(fā)

物理層

通信方式

• 單工通信：單向傳輸

• 半雙工通信：雙向交替?zhèn)鬏?/p>

• 全雙工通信：雙向同時(shí)傳輸

帶通調(diào)制

• 模擬信號(hào)是連續(xù)的信號(hào)，數(shù)字信號(hào)是離散的信號(hào)

• 帶通調(diào)制把數(shù)字信號(hào)轉(zhuǎn)換為模擬信號(hào)

鏈路層

基本功能

• 成幀（給IP數(shù)據(jù)包添加首部和尾部）

• 透明傳輸（如果幀的數(shù)據(jù)部分含有和首部尾部相同的內(nèi)容小槐，需插入轉(zhuǎn)義符拇派，接收端處理后可以還原數(shù)據(jù)；整個(gè)過程對(duì)用戶透明）

• 差錯(cuò)檢測(cè)（用循環(huán)冗余檢驗(yàn)CRC檢查比特差錯(cuò)）

信道分類

• 廣播信道：一對(duì)多

• 點(diǎn)對(duì)點(diǎn)信道：一對(duì)一

信道復(fù)用

• 頻分復(fù)用：所有主機(jī)在相同的時(shí)間占用不同的頻率帶寬資源

• 時(shí)分復(fù)用：所有主機(jī)在不同的時(shí)間占用相同的（所有的）頻率帶寬資源【ABCDABCD】

• 統(tǒng)計(jì)時(shí)分復(fù)用：不固定每個(gè)用戶在時(shí)分復(fù)用幀中的位置凿跳，只要有數(shù)據(jù)就集中起來組成統(tǒng)計(jì)時(shí)分復(fù)用幀然后發(fā)送【ACDABBCD】

• 波分復(fù)用：光的頻分復(fù)用

• 碼分復(fù)用

  • 為每個(gè)用戶分配 m bit 的碼片件豌，并且所有的碼片正交

  • 擁有該碼片的用戶發(fā)送比特 1 時(shí)就發(fā)送該碼片，發(fā)送比特 0 時(shí)就發(fā)送該碼片的反碼

  • 接收端使用碼片 對(duì)接收到的數(shù)據(jù)進(jìn)行內(nèi)積運(yùn)算時(shí)控嗜，結(jié)果為 0 的是其它用戶發(fā)送的數(shù)據(jù)茧彤，結(jié)果為 1 的是用戶發(fā)送的比特 1，結(jié)果為 -1 的是用戶發(fā)送的比特 0

CSMA/CD 協(xié)議

• 總線型網(wǎng)絡(luò)疆栏，許多主機(jī)以多點(diǎn)的方式連接到總線上

• 每個(gè)主機(jī)都必須不停地監(jiān)聽信道曾掂。在發(fā)送前惫谤，如果監(jiān)聽到信道正在使用，就必須等待

• 雖然每個(gè)主機(jī)在發(fā)送數(shù)據(jù)之前都已經(jīng)監(jiān)聽到信道為空閑遭殉，但是由于電磁波的傳播時(shí)延的存在石挂，還是有可能會(huì)發(fā)生碰撞

• 當(dāng)發(fā)生碰撞時(shí)，站點(diǎn)要停止發(fā)送险污，等待一段時(shí)間再發(fā)送

PPP協(xié)議

用戶計(jì)算機(jī)和 ISP 進(jìn)行通信時(shí)所使用的數(shù)據(jù)鏈路層協(xié)議

MAC地址

鏈路層地址痹愚，用于唯一標(biāo)識(shí)網(wǎng)絡(luò)適配器（網(wǎng)卡）

以太網(wǎng)

• 星型拓?fù)浣Y(jié)構(gòu)局域網(wǎng)

• 使用廣播信道

• 使用交換機(jī)根據(jù)MAC地址進(jìn)行存儲(chǔ)轉(zhuǎn)發(fā)

交換機(jī)

• 交換表中存儲(chǔ)著 MAC 地址到接口的映射

• 交換機(jī)可以自學(xué)習(xí)交換表的內(nèi)容，即插即用蛔糯，不需要網(wǎng)絡(luò)管理員手動(dòng)配置交換表

虛擬局域網(wǎng) VLAN

虛擬局域網(wǎng)可以建立與物理位置無關(guān)的邏輯組拯腮，只有在同一個(gè)虛擬局域網(wǎng)中的成員才會(huì)收到鏈路層廣播信息

網(wǎng)絡(luò)層

IP數(shù)據(jù)報(bào)格式

• 版本 : 有 4（IPv4，32位）和 6（IPv6蚁飒，128位）兩個(gè)值

• 總長度：首部長度+數(shù)據(jù)部分長度

• 生存時(shí)間 TTL：防止無法交付的數(shù)據(jù)報(bào)在互聯(lián)網(wǎng)中不斷兜圈子

• 首部檢驗(yàn)和：數(shù)據(jù)報(bào)每經(jīng)過一個(gè)路由器动壤，都要重新計(jì)算檢驗(yàn)和，首部檢驗(yàn)和不包括對(duì)數(shù)據(jù)部分的檢驗(yàn)

• 標(biāo)識(shí)：在數(shù)據(jù)報(bào)長度過長從而發(fā)生分片的情況下淮逻，相同數(shù)據(jù)報(bào)的不同分片具有相同的標(biāo)識(shí)

• 片偏移：和標(biāo)識(shí)符一起琼懊，用于發(fā)生分片的情況

無分類編址 CIDR

• 128.14.35.7/20 表示前 20 位為網(wǎng)絡(luò)前綴

• 子網(wǎng)掩碼首 1 長度為網(wǎng)絡(luò)前綴的長度，對(duì)長度沒有規(guī)定

• IP地址與子網(wǎng)掩碼相與可得子網(wǎng)ip

ARP協(xié)議

• ARP 實(shí)現(xiàn)由 IP 地址得到 MAC 地址

• 每個(gè)主機(jī)都有一個(gè) ARP 高速緩存爬早，里面有本局域網(wǎng)上的各主機(jī)和路由器的 IP 地址到 MAC 地址的映射表

ICMP協(xié)議

• Ping：向目的主機(jī)發(fā)送 ICMP Echo 請(qǐng)求報(bào)文哼丈，目的主機(jī)收到之后會(huì)發(fā)送 Echo 回答報(bào)文。Ping 會(huì)根據(jù)時(shí)間和成功響應(yīng)的次數(shù)估算出數(shù)據(jù)包往返時(shí)間以及丟包率

• Traceroute：跟蹤一個(gè)分組從源點(diǎn)到終點(diǎn)的路徑

VPN 虛擬專用網(wǎng)

• 機(jī)構(gòu)內(nèi)的計(jì)算機(jī)可以使用僅在本機(jī)構(gòu)有效的 IP 地址（專用地址）

• 機(jī)構(gòu)內(nèi)的主機(jī)只與本機(jī)構(gòu)內(nèi)的其它主機(jī)通信

NAT 網(wǎng)絡(luò)地址轉(zhuǎn)換

• 專用網(wǎng)內(nèi)部的主機(jī)使用本地 IP 地址又想和互聯(lián)網(wǎng)上的主機(jī)通信時(shí)筛严，可以使用 NAT 來將本地 IP 轉(zhuǎn)換為全球 IP

• 分為靜態(tài)轉(zhuǎn)換（轉(zhuǎn)換得到的全球IP地址固定不變）和動(dòng)態(tài)NAT轉(zhuǎn)換

路由器分組轉(zhuǎn)發(fā)流程

• 從數(shù)據(jù)報(bào)的首部提取目的主機(jī)的 IP 地址 D醉旦，得到目的網(wǎng)絡(luò)地址 N

• 若 N 就是與此路由器直接相連的某個(gè)網(wǎng)絡(luò)地址桨啃，則進(jìn)行直接交付

• 若路由表中有目的地址為 D 的特定主機(jī)路由车胡，則把數(shù)據(jù)報(bào)傳送給表中所指明的下一跳路由器

• 若路由表中有到達(dá)網(wǎng)絡(luò) N 的路由，則把數(shù)據(jù)報(bào)傳送給路由表中所指明的下一跳路由器

• 若路由表中有一個(gè)默認(rèn)路由照瘾，則把數(shù)據(jù)報(bào)傳送給路由表中所指明的默認(rèn)路由器

• 報(bào)告轉(zhuǎn)發(fā)分組出錯(cuò)

傳輸層

UDP vs TCP

TCP三次握手

• 客戶端隨機(jī)生成序列號(hào)x，向服務(wù)端發(fā)送連接請(qǐng)求報(bào)文碳却，進(jìn)入SYN_SENT狀態(tài)

  • SYN=1, ACK=0, seq=x

• 服務(wù)端收到連接請(qǐng)求報(bào)文，同意建立連接則隨機(jī)生成序列號(hào)y笑旺，向客戶端發(fā)送連接確認(rèn)報(bào)文昼浦，進(jìn)入SYN_RCVD狀態(tài)

  • SYN=1, ACK=1, seq=y, ack=x+1

• 客戶端收到連接確認(rèn)報(bào)文，再次向服務(wù)端發(fā)出確認(rèn)報(bào)文筒主，連接建立关噪，進(jìn)入ESTABLISHED狀態(tài)

  • ACK=1, seq=x+1, ack=y+1

• 服務(wù)端收到確認(rèn)報(bào)文后鸟蟹，連接建立，進(jìn)入ESTABLISHED狀態(tài)

三次握手的原因

• 客戶端發(fā)送的連接請(qǐng)求如果在網(wǎng)絡(luò)中滯留使兔，那么就會(huì)隔很長一段時(shí)間才能收到服務(wù)器端發(fā)回的連接確認(rèn)建钥。客戶端等待一個(gè)超時(shí)重傳時(shí)間之后虐沥，就會(huì)重新請(qǐng)求連接熊经。但是這個(gè)滯留的連接請(qǐng)求最后還是會(huì)到達(dá)服務(wù)器，如果不進(jìn)行三次握手欲险，那么服務(wù)器就會(huì)打開兩個(gè)連接镐依。如果有第三次握手，客戶端會(huì)忽略服務(wù)器之后發(fā)送的對(duì)滯留連接請(qǐng)求的連接確認(rèn)天试，不進(jìn)行第三次握手槐壳，因此就不會(huì)再次打開連接

• 兩次握手無法保證Client正確接收第二次握手的報(bào)文（Server無法確認(rèn)Client是否收到）

為什么不用四次握手

因?yàn)閠cp是全雙工的，三次已經(jīng)確認(rèn)了數(shù)據(jù)在兩個(gè)方向上都是可以正確到達(dá)的

第三次握手中客戶端的報(bào)文未到達(dá)服務(wù)端會(huì)怎樣

• 服務(wù)端：由于Server沒有收到ACK確認(rèn)喜每，因此會(huì)重發(fā)之前的SYN+ACK（默認(rèn)重發(fā)五次务唐，之后自動(dòng)關(guān)閉連接進(jìn)入CLOSED狀態(tài)）；在Server進(jìn)入CLOSED狀態(tài)之后带兜，如果Client向服務(wù)器發(fā)送數(shù)據(jù)枫笛，服務(wù)器會(huì)以RST包應(yīng)答

• 客戶端：收到服務(wù)端重發(fā)的SYN+ACK報(bào)文后，重新傳ACK給Server

如果已經(jīng)建立了連接鞋真，但客戶端出現(xiàn)了故障怎么辦

服務(wù)器每收到一次客戶端的請(qǐng)求后都會(huì)重新復(fù)位一個(gè)計(jì)時(shí)器崇堰，時(shí)間通常是設(shè)置為2小時(shí)，若兩小時(shí)還沒有收到客戶端的任何數(shù)據(jù)涩咖，服務(wù)器就會(huì)發(fā)送一個(gè)探測(cè)報(bào)文段海诲，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個(gè)探測(cè)報(bào)文仍然沒反應(yīng)檩互，服務(wù)器就認(rèn)為客戶端出了故障特幔，接著就關(guān)閉連接

TCP四次揮手

• 客戶端發(fā)送連接釋放報(bào)文

  • FIN=1, seq=u

• 服務(wù)端收到釋放報(bào)文后，發(fā)出確認(rèn)報(bào)文闸昨，此時(shí)TCP半關(guān)閉蚯斯，服務(wù)端能向客戶端發(fā)送數(shù)據(jù)，但客戶端不能向服務(wù)端發(fā)送數(shù)據(jù)饵较，服務(wù)端進(jìn)入CLOSE-WAIT狀態(tài)

  • ACK=1, seq=v, ack=u+1

• 服務(wù)端數(shù)據(jù)傳輸完成后拍嵌，發(fā)出連接釋放報(bào)文

  • FIN=1, ACK=1, seq=w, ack=u+1

• 客戶端收到連接釋放報(bào)文后發(fā)出確認(rèn)，客戶端進(jìn)入TIME-WAIT 狀態(tài)循诉，等待 2 MSL（最大報(bào)文存活時(shí)間）后如果沒有收到服務(wù)端的回復(fù)横辆，則釋放連接

  • ACK=1, seq=u+1, ack=w+1

• 服務(wù)端收到客戶端的確認(rèn)后，釋放連接

四次揮手的原因

• 客戶端發(fā)送了 FIN 連接釋放報(bào)文之后茄猫，服務(wù)器收到了這個(gè)報(bào)文狈蚤，就進(jìn)入了 CLOSE-WAIT 狀態(tài)困肩。這個(gè)狀態(tài)是為了讓服務(wù)器端發(fā)送還未傳送完畢的數(shù)據(jù)，傳送完畢之后脆侮，服務(wù)器會(huì)發(fā)送 FIN 連接釋放報(bào)文

• 客戶端接收到服務(wù)器端的 FIN 報(bào)文后進(jìn)入 TIME-WAIT狀態(tài)锌畸，要等最大數(shù)據(jù)包生存期的兩倍，是為了：

  • 確保最后一個(gè)確認(rèn)報(bào)文能夠到達(dá)靖避。如果服務(wù)端沒收到客戶端發(fā)送來的確認(rèn)報(bào)文潭枣，那么就會(huì)重新發(fā)送連接釋放請(qǐng)求報(bào)文，那么客戶端就會(huì)重傳確認(rèn)報(bào)文

  • 讓本連接持續(xù)時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文都從網(wǎng)絡(luò)中消失筋蓖，使得下一個(gè)新的連接不會(huì)出現(xiàn)舊連接的報(bào)文

TCP可靠傳輸

• 超時(shí)重傳：如果一個(gè)已經(jīng)發(fā)送的報(bào)文段在超時(shí)時(shí)間內(nèi)沒有收到確認(rèn)卸耘，那么就重傳這個(gè)報(bào)文段

• 確認(rèn)機(jī)制：當(dāng)TCP收到發(fā)自TCP連接另一端的數(shù)據(jù)，它將發(fā)送一個(gè)確認(rèn)

• 校驗(yàn)和：校驗(yàn)出包有錯(cuò)粘咖，丟棄報(bào)文段蚣抗，不給出響應(yīng)

• 如果有必要，TCP將對(duì)收到的數(shù)據(jù)進(jìn)行重新排序瓮下，將收到的數(shù)據(jù)以正確的順序交給應(yīng)用層

TCP流量控制

• 接收方發(fā)送的確認(rèn)報(bào)文中的窗口字段可以用來控制發(fā)送方窗口大小翰铡，從而影響發(fā)送方的發(fā)送速率，保證接收方來得及接收

• 發(fā)送窗口

  • 如果發(fā)送窗口左部的字節(jié)已經(jīng)發(fā)送并且收到了確認(rèn)讽坏，那么就將發(fā)送窗口向右滑動(dòng)一定距離锭魔，直到左部第一個(gè)字節(jié)不是已發(fā)送并且已確認(rèn)的狀態(tài)

  • 發(fā)送方得到一個(gè)字節(jié)的確認(rèn)之后，就知道這個(gè)字節(jié)之前的所有字節(jié)都已經(jīng)被接收

• 接收窗口

  • 接收窗口左部字節(jié)已經(jīng)發(fā)送確認(rèn)并交付主機(jī)路呜，就向右滑動(dòng)接收窗口

  • 接收窗口只會(huì)對(duì)窗口內(nèi)最后一個(gè)按序到達(dá)的字節(jié)進(jìn)行確認(rèn)迷捧，例如接收窗口已經(jīng)收到的字節(jié)為 {31, 34, 35}，其中 {31} 按序到達(dá)胀葱，而 {34, 35} 就不是漠秋，因此只對(duì)字節(jié) 31 進(jìn)行確認(rèn)

  • 如果接收方?jīng)]有能力接收數(shù)據(jù)，就會(huì)將接收窗口設(shè)置為0抵屿，這時(shí)發(fā)送方必須暫停發(fā)送數(shù)據(jù)庆锦，但是會(huì)啟動(dòng)一個(gè)持續(xù)計(jì)時(shí)器(persistence timer)，到期后發(fā)送一個(gè)大小為1字節(jié)的探測(cè)數(shù)據(jù)包轧葛，以查看接收窗口狀態(tài)搂抒。如果接收方能夠接收數(shù)據(jù)，就會(huì)在返回的報(bào)文中更新接收窗口大小尿扯，恢復(fù)數(shù)據(jù)傳送

TCP擁塞控制

• 必要性：流控只簡單地表明了接收方的處理能力求晶，并不能代表中間網(wǎng)絡(luò)的處理能力

• 慢開始與擁塞避免：慢開始：cwnd初始值為1，每收到一次確認(rèn)cwnd*=2衷笋；擁塞避免：cwnd達(dá)到ssthresh時(shí)芳杏，每收到一次確認(rèn)cwnd+=1；如果出現(xiàn)超時(shí)，令ssthresh = cwnd / 2蚜锨，cwnd=1

• 快重傳與快恢復(fù)：快重傳：發(fā)送方收到3個(gè)重復(fù)確認(rèn)時(shí)可知下一個(gè)報(bào)文段丟失，立即重傳下一個(gè)報(bào)文段慢蜓；快恢復(fù)：考慮到如果網(wǎng)絡(luò)出現(xiàn)擁塞的話就不會(huì)收到好幾個(gè)重復(fù)的確認(rèn)亚再，所以發(fā)送方現(xiàn)在認(rèn)為網(wǎng)絡(luò)可能沒有出現(xiàn)擁塞，所以此時(shí)不執(zhí)行慢開始算法晨抡，而是直接令cwnd = ssthresh氛悬，從而進(jìn)入擁塞避免執(zhí)行擁塞避免算法

窗口

• cwnd：擁塞窗口；awnd：接收方指定的發(fā)送窗口

• 實(shí)際的發(fā)送窗口：W=min(cwnd,awnd)

TCP的四個(gè)隊(duì)列

• receive隊(duì)列

  • 是真正的接收隊(duì)列

  • 操作系統(tǒng)收到的TCP數(shù)據(jù)包經(jīng)過檢查和處理后耘柱，就會(huì)保存到這個(gè)隊(duì)列中

• backlog隊(duì)列

  • 是備用隊(duì)列

  • 當(dāng)用戶正在對(duì)socket進(jìn)行系統(tǒng)調(diào)用如捅，如recv時(shí)，操作系統(tǒng)收到數(shù)據(jù)包時(shí)會(huì)將數(shù)據(jù)包保存到 backlog隊(duì)列中

• prequeue隊(duì)列

  • 是預(yù)存隊(duì)列

  • 當(dāng)socket沒有正在被用戶進(jìn)程使用時(shí)调煎，也就是用戶進(jìn)程調(diào)用了read或者recv系統(tǒng)調(diào)用镜遣，但是進(jìn)入了睡眠狀態(tài)時(shí)，操作系統(tǒng)直接將收到的報(bào)文保存在 prequeue中

• out_of_order隊(duì)列

  • 是亂序隊(duì)列

  • 隊(duì)列存儲(chǔ)的是亂序的報(bào)文士袄，操作系統(tǒng)收到的報(bào)文并不是TCP準(zhǔn)備接收的下一個(gè)序號(hào)的報(bào)文悲关，則放入 out_of_order隊(duì)列

TCP接收?qǐng)?bào)文的流程

TCP粘包

• 產(chǎn)生原因

  • 只有TCP有粘包現(xiàn)象，UDP永遠(yuǎn)不會(huì)粘包娄柳，因?yàn)門CP是基于數(shù)據(jù)流的協(xié)議寓辱，而UDP是基于數(shù)據(jù)報(bào)的協(xié)議

  • 接收方不知道消息之間的界限，不知道一次性提取多少字節(jié)的數(shù)據(jù)

  • TCP為提高傳輸效率赤拒，會(huì)根據(jù)nagel優(yōu)化算法（將數(shù)據(jù)量小的秫筏，且時(shí)間間隔較短的數(shù)據(jù)一次性發(fā)給對(duì)方）把數(shù)據(jù)合成一個(gè)TCP段后一次發(fā)送出去，這樣接收方就收到了粘包數(shù)據(jù)

• 發(fā)生時(shí)機(jī)

  • 發(fā)送端需要等緩沖區(qū)滿才發(fā)送出去挎挖，造成粘包（發(fā)送數(shù)據(jù)時(shí)間間隔很短这敬，數(shù)據(jù)了很小，會(huì)合到一起肋乍，產(chǎn)生粘包）

  • 接收方不及時(shí)接收緩沖區(qū)的包鹅颊，造成多個(gè)包接收（客戶端發(fā)送了一段數(shù)據(jù)，服務(wù)端只收了一小部分墓造，服務(wù)端下次再收的時(shí)候還是從緩沖區(qū)拿上次遺留的數(shù)據(jù)堪伍，產(chǎn)生粘包）

• 解決方法

  • 發(fā)送定長包

  • 包尾加上\r\n標(biāo)記

  • 包頭加上包體長度

  • 使用更加復(fù)雜的應(yīng)用層協(xié)議

TCP首部

• 固定部分：20字節(jié)

  • 源端口、目的端口

  • 序號(hào)觅闽、確認(rèn)號(hào)

  • 數(shù)據(jù)偏移：即首部長度

  • 控制位：6個(gè)保留帝雇，剩下6個(gè)是

    • URG：告訴系統(tǒng)此報(bào)文段中有緊急數(shù)據(jù)，應(yīng)盡快發(fā)送

    • ACK：僅當(dāng)ACK = 1時(shí)確認(rèn)號(hào)字段才有效蛉拙；TCP規(guī)定尸闸，在連接建立后所有的傳送的報(bào)文段都必須把ACK置為1

    • PSH：在一端的應(yīng)用進(jìn)程希望在鍵入一個(gè)命令后立即就能收到對(duì)方的響應(yīng)；接收方TCP收到PSH=1的報(bào)文段，就盡快地（即“推送”向前）交付接收應(yīng)用進(jìn)程吮廉。而不用再等到整個(gè)緩存都填滿了后再向上交付

    • RST：當(dāng)RST=1時(shí)苞尝，表明TCP連接中出現(xiàn)了嚴(yán)重錯(cuò)誤（如由于主機(jī)崩潰或其他原因），必須釋放連接宦芦，然后再重新建立傳輸連接宙址。RST置為1還用來拒絕一個(gè)非法的報(bào)文段或拒絕打開一個(gè)連接

    • SYN：SYN置為1就表示這是一個(gè)連接請(qǐng)求或連接接受報(bào)文

    • FIN：當(dāng)FIN=1時(shí)，表明此報(bào)文段的發(fā)送發(fā)的數(shù)據(jù)已發(fā)送完畢调卑，并要求釋放運(yùn)輸連接

  • 窗口：接收窗口的大小

  • 校驗(yàn)和：偽首部抡砂、首部和數(shù)據(jù)的校驗(yàn)和

  • 緊急指針：僅在URG=1時(shí)才有意義，它指出本報(bào)文段中的緊急數(shù)據(jù)的字節(jié)數(shù)（緊急數(shù)據(jù)結(jié)束后就是普通數(shù)據(jù)）恬涧；當(dāng)所有緊急數(shù)據(jù)都處理完時(shí)注益，TCP就告訴應(yīng)用程序恢復(fù)到正常操作；即使窗口為0時(shí)也可以發(fā)送緊急數(shù)據(jù)

• 長度可變部分

  • 選項(xiàng)（長度可變）

  • 填充部分

UDP首部

• 固定為8字節(jié)

  • 源端口溯捆、目的端口

  • UDP長度：偽首部丑搔、首部和數(shù)據(jù)的總長

  • 校驗(yàn)和：偽首部、首部和數(shù)據(jù)的校驗(yàn)和

TCP/UDP偽首部

• 在首部前面提揍，不屬于首部

• 長度為12字節(jié)

• 作用：這樣的校驗(yàn)和低匙，既校驗(yàn)了TCP&UDP用戶數(shù)據(jù)的源端口號(hào)和目的端口號(hào)以及TCP&UDP用戶數(shù)據(jù)報(bào)的數(shù)據(jù)部分，又檢驗(yàn)了IP數(shù)據(jù)報(bào)的源IP地址和目的地址碳锈。偽報(bào)頭保證TCP&UDP數(shù)據(jù)單元到達(dá)正確的目的地址

• 內(nèi)容：

  • 源IP顽冶、目的IP

  • 8位填充0

  • 協(xié)議

  • TCP/UDP長度

應(yīng)用層

web頁面請(qǐng)求過程

• 若A沒有 IP 地址：DHCP（用的是UDP）

  • A發(fā)送DHCP請(qǐng)求報(bào)文給交換機(jī)，目的IP是255.255.255.255售碳，源 IP是0.0.0.0强重；目的MAC是FF:FF:FF:FF:FF:FF，源MAC是自己的MAC

  • 交換機(jī)洪泛贸人，該局域網(wǎng)的DHCP 服務(wù)器返回IP间景、DNS服務(wù)器IP、默認(rèn)網(wǎng)關(guān)路由器的 IP 地址和子網(wǎng)掩碼

  • 交換機(jī)把報(bào)文單發(fā)給A

• 若A的ARP緩存中沒有網(wǎng)關(guān)路由器的IP和MAC的映射：ARP

  • A發(fā)送ARP請(qǐng)求給交換機(jī)

  • 交換機(jī)洪泛艺智，網(wǎng)關(guān)路由器返回其MAC

  • 交換機(jī)把報(bào)文單發(fā)給A

• 若瀏覽器緩存和OS緩存中沒有HTTP服務(wù)器的域名和IP的映射：DNS（用的是UDP）

  • A通過交換機(jī)發(fā)送DNS報(bào)文給網(wǎng)關(guān)路由器

  • 網(wǎng)關(guān)路由器把報(bào)文轉(zhuǎn)發(fā)給DNS服務(wù)器

  • DNS服務(wù)器在 DNS 數(shù)據(jù)庫中查找待解析的域名

    • A到本地域名服務(wù)器進(jìn)行遞歸查詢：即本地域名服務(wù)器代替它進(jìn)行查詢

    • 本地域名服務(wù)器進(jìn)行迭代查詢：先通過根域名服務(wù)器知道.com這個(gè)頂級(jí)域名服務(wù)器的IP倘要；再通過.com頂級(jí)服務(wù)器知道.baidu這個(gè)二級(jí)域名服務(wù)器的IP

  • 原路返回

  • A根據(jù)IP生成TCP套接字

• HTTP

  • TCP三握手和HTTP服務(wù)器建立連接：端口是80

  • 瀏覽器生成 HTTP GET 報(bào)文，并交付給 HTTP 服務(wù)器

  • HTTP 服務(wù)器生成一個(gè) HTTP 響應(yīng)報(bào)文十拣，將 Web 頁面內(nèi)容放入報(bào)文主體中封拧，發(fā)回給客戶端

  • 瀏覽器收到 HTTP 響應(yīng)報(bào)文后，抽取出 Web 頁面內(nèi)容夭问，之后進(jìn)行渲染泽西，顯示 Web 頁面

• 瀏覽器

  • 瀏覽器處理HTTP響應(yīng)報(bào)文中的主體內(nèi)容，首先使用loader模塊加載相應(yīng)的資源【loader模塊有兩條資源加載路徑：主資源加載路徑和派生資源加載路徑：主資源即google主頁的index.html文件 缰趋，派生資源即index.html文件中用到的資源】

    • 瀏覽器的Parser模塊解析主資源的內(nèi)容捧杉，生成派生資源對(duì)應(yīng)的DOM結(jié)構(gòu)

    • 后根據(jù)需求觸發(fā)派生資源的加載流程（比如陕见，在解析過程中，如果遇到img的起始標(biāo)簽味抖，會(huì)創(chuàng)建相應(yīng)的image元素HTMLImageElement评甜，接著依據(jù)img標(biāo)簽的內(nèi)容設(shè)置HTMLImageElement的屬性。在設(shè)置src屬性時(shí)仔涩，會(huì)觸發(fā)圖片資源加載蜕着，發(fā)起加載資源請(qǐng)求）【這里常見的優(yōu)化點(diǎn)是對(duì)派生資源使用緩存】

  • 構(gòu)建DOM樹（經(jīng)過了Parser模塊的處理，瀏覽器把頁面文本轉(zhuǎn)換成了一棵節(jié)點(diǎn)帶CSS Style红柱、會(huì)響應(yīng)自定義事件的Styled DOM樹）

    • 使用parse模塊解析HTML

      • 解碼：將網(wǎng)絡(luò)上接收到的經(jīng)過編碼的字節(jié)流，解碼成Unicode字符

      • 分詞：按照一定的切詞規(guī)則蓖乘，將Unicode字符流切成一個(gè)個(gè)的詞語(Tokens)

      • 解析：根據(jù)詞語的語義锤悄，創(chuàng)建相應(yīng)的節(jié)點(diǎn)(Node)

      • 建樹：將節(jié)點(diǎn)關(guān)聯(lián)到一起，創(chuàng)建DOM樹

    • 使用parse模塊解析CSS

      • 解析出一系列CSSRule嘉抒，含有CSS屬性和值的Key-Value集合

      • 進(jìn)行CSSRule的匹配過程零聚，即尋找滿足每條CSS規(guī)則Selector部分的HTML元素，然后將其Declaration聲明部分應(yīng)用于該元素

    • 使用parse模塊解析JS

      • 動(dòng)態(tài)地改變DOM樹（比如為DOM節(jié)點(diǎn)添加事件響應(yīng)處理函數(shù)）些侍，即根據(jù)時(shí)間（timer）或事件（event）映射一棵DOM樹到另一棵DOM樹

  • 構(gòu)建Render樹

    • Render樹用于表示文檔的可視信息隶症，記錄了文檔中每個(gè)可視元素的布局及渲染方式

    • DOM樹上的節(jié)點(diǎn)與Render樹上的節(jié)點(diǎn)并不是一一對(duì)應(yīng)的。只有DOM樹的根節(jié)點(diǎn)及可視節(jié)點(diǎn)才會(huì)創(chuàng)建對(duì)應(yīng)的RenderObject節(jié)點(diǎn)

  • 構(gòu)建Render Layer樹

    • 以層為節(jié)點(diǎn)組織文檔的可視信息岗宣，網(wǎng)頁上的每一層對(duì)應(yīng)一個(gè)Render Layer對(duì)象

    • 每個(gè)RenderLayer樹的節(jié)點(diǎn)都對(duì)應(yīng)著一棵Render樹的子樹蚂会，這棵子樹上所有Render節(jié)點(diǎn)都在網(wǎng)頁的同一層顯示

  • 布局和渲染

    • 布局就是安排和計(jì)算頁面中每個(gè)元素大小位置等幾何信息；HTML采用流式布局模型耗式，基本的原則是頁面元素在順序遍歷過程中依次按從左至右胁住、從上至下的排列方式確定各自的位置區(qū)域

    • 渲染：將Render樹映射成可視的圖形，它會(huì)遍歷Render樹調(diào)用每個(gè)Render節(jié)點(diǎn)的繪制方法將其內(nèi)容顯示在一塊畫布或者位圖上刊咳，并最終呈現(xiàn)在瀏覽器應(yīng)用窗口中成為用戶看到的實(shí)際頁面

HTTP協(xié)議（80端口）

• http方法

  • GET：獲取資源

  • POST：傳輸實(shí)體主體，如提交表單等

  • HEAD：獲取報(bào)文首部，主要用于確認(rèn) URL 的有效性以及資源更新的日期時(shí)間

  • OPTIONS：查詢支持的方法

  • PUT：上傳文件（由于自身不帶驗(yàn)證機(jī)制睦柴，任何人都可以上傳文件醉途，因此存在安全性問題），從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容

  • PATCH：對(duì)資源進(jìn)行部分修改（PUT 也可以用于修改資源跷坝，但是只能完全替代原始資源酵镜，PATCH 允許部分修改）

  • DELETE：刪除文件，與 PUT 功能相反柴钻，并且同樣不帶驗(yàn)證機(jī)制

  • CONNECT：要求在與代理服務(wù)器通信時(shí)建立隧道笋婿，把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸

  • TRACE：服務(wù)器會(huì)將通信路徑返回給客戶端

• GET vs POST

  • GET用于獲取資源，POST用于傳輸實(shí)體主體顿颅，比如提交表單等

  • GET不會(huì)改變服務(wù)器存儲(chǔ)的數(shù)據(jù)缸濒，POST可能會(huì)改變服務(wù)器狀態(tài)足丢，比如上傳了表單，存儲(chǔ)到了數(shù)據(jù)庫中

  • GET的參數(shù)在URL中庇配，POST的參數(shù)在實(shí)體主體中

  • GET請(qǐng)求可被緩存斩跌、收藏、保留到歷史記錄捞慌，且其請(qǐng)求數(shù)據(jù)以明文出現(xiàn)在URL中耀鸦；POST的參數(shù)不會(huì)被保存，安全性相對(duì)較高

  • GET請(qǐng)求在URL中傳送的參數(shù)是有長度限制的啸澡，而POST沒有

  • GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包袖订、POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包：對(duì)于GET方式的請(qǐng)求，瀏覽器會(huì)把http header和data一并發(fā)送出去嗅虏，服務(wù)器響應(yīng)200（返回?cái)?shù)據(jù)）洛姑；而對(duì)于POST，瀏覽器先發(fā)送header皮服，服務(wù)器響應(yīng)100 continue楞艾，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok（返回?cái)?shù)據(jù)）

• http狀態(tài)碼

  • 100 continue：表示到目前為止都很正常

  • 2xx 成功

    • 200 ok：請(qǐng)求成功龄广；一般用于GET與POST請(qǐng)求

    • 203 非授權(quán)信息：請(qǐng)求成功硫眯，但返回的meta信息不在原始的服務(wù)器，而是一個(gè)副本

    • 204 無內(nèi)容：服務(wù)器成功處理择同，但未返回內(nèi)容

  • 3xx 重定向

    • 301 永久移動(dòng)：請(qǐng)求的資源已被永久的移動(dòng)到新URI两入，返回信息會(huì)包括新的URI，瀏覽器會(huì)自動(dòng)定向到新URI敲才，今后任何新的請(qǐng)求都應(yīng)使用新的URI代替

    • 302 臨時(shí)移動(dòng)：資源只是臨時(shí)被移動(dòng)谆刨，客戶端應(yīng)繼續(xù)使用原有URI

  • 4xx 客戶端錯(cuò)誤

    • 400 請(qǐng)求報(bào)文語法錯(cuò)誤

    • 401 請(qǐng)求中缺少認(rèn)證信息

    • 403 請(qǐng)求被拒絕

    • 404 服務(wù)器無法根據(jù)客戶端的請(qǐng)求找到資源

    • 405 客戶端請(qǐng)求中的方法被禁止

  • 5xx 服務(wù)端錯(cuò)誤

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

    • 502 作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)归斤，從遠(yuǎn)程服務(wù)器接收到了一個(gè)無效的響應(yīng)

    • 503 由于超載或系統(tǒng)維護(hù)痊夭，服務(wù)器暫時(shí)無法處理客戶端的請(qǐng)求

  • 600 源站沒有返回響應(yīng)頭部，只返回實(shí)體內(nèi)容

• 短連接與長連接

  • 當(dāng)瀏覽器訪問一個(gè)包含多張圖片的 HTML 頁面時(shí)脏里，除了請(qǐng)求訪問的 HTML 頁面資源她我，還會(huì)請(qǐng)求圖片資源。如果每進(jìn)行一次 HTTP 通信就要新建一個(gè) TCP 連接迫横，那么開銷會(huì)很大

  • 長連接只需要建立一次 TCP 連接就能進(jìn)行多次 HTTP 通信

• 流水線

  • 默認(rèn)情況下番舆，HTTP 請(qǐng)求是按順序發(fā)出的，下一個(gè)請(qǐng)求只有在當(dāng)前請(qǐng)求收到響應(yīng)之后才會(huì)被發(fā)出

  • 流水線是在同一條長連接上連續(xù)發(fā)出請(qǐng)求矾踱，而不用等待響應(yīng)返回

• 各版本區(qū)別

  • 1.0 vs 1.1

    • HTTP1.1中默認(rèn)開啟長連接恨狈；HTTP1.0需要使用keep-alive參數(shù)來告知服務(wù)器端要建立一個(gè)長連接

    • 1.1節(jié)約帶寬：支持只發(fā)送header信息（不帶任何body信息），如果服務(wù)器認(rèn)為客戶端有權(quán)限請(qǐng)求服務(wù)器呛讲，則返回100禾怠，客戶端接收到100才開始把請(qǐng)求body發(fā)送到服務(wù)器返奉；如果返回401，客戶端就可以不用發(fā)送請(qǐng)求body了

    • 在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址吗氏，因此芽偏，請(qǐng)求消息中的URL并沒有傳遞主機(jī)名（hostname），HTTP1.0沒有host域弦讽。隨著虛擬主機(jī)技術(shù)的發(fā)展污尉，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)，它們共享一個(gè)IP地址往产。HTTP1.1的請(qǐng)求消息和響應(yīng)消息都支持host域被碗，且請(qǐng)求消息中如果沒有host域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）

    • 1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突仿村；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除

  • 1.1 vs 2.0

    • HTTP2.0使用了多路復(fù)用的技術(shù)锐朴，做到同一個(gè)連接并發(fā)處理多個(gè)請(qǐng)求（原長連接是同一連接串行處理多個(gè)請(qǐng)求：請(qǐng)求1-回復(fù)1-請(qǐng)求2-回復(fù)2...）

    • HTTP2.0使用HPACK算法對(duì)header的數(shù)據(jù)進(jìn)行壓縮，這樣數(shù)據(jù)體積小了

    • 2.0允許服務(wù)器在客戶端未請(qǐng)求時(shí)推送數(shù)據(jù)給客戶端奠宜；這樣客戶端可以直接從本地加載這些資源，不用再通過網(wǎng)絡(luò)

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

  • 請(qǐng)求行：方法瞻想、協(xié)議版本压真、URL（包括參數(shù)信息）

  • 請(qǐng)求頭部：是一個(gè)個(gè)的key-value值，包括瀏覽器類型蘑险，客戶端支持的數(shù)據(jù)格式滴肿，主機(jī)名等

  • 空行：表示header和請(qǐng)求數(shù)據(jù)的分隔

  • 請(qǐng)求數(shù)據(jù)：GET方法沒有攜帶數(shù)據(jù)， POST方法攜帶一個(gè)body

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

  • 狀態(tài)行：狀態(tài)碼佃迄、協(xié)議版本

  • 消息報(bào)頭：時(shí)間戳泼差、使用的字符集、正文的長度呵俏、最后修改時(shí)間堆缘、媒體格式類型（html、圖片普碎、json吼肥、pdf等）等

  • 空行：分割消息報(bào)頭和響應(yīng)正文

  • 響應(yīng)正文

• HTTP特點(diǎn)

  • 無狀態(tài)：http服務(wù)器并不保存關(guān)于客戶的任何信息，HTTP/1.1 引入 Cookie 來保存狀態(tài)信息

  • 無連接：無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求麻车。服務(wù)器處理完客戶的請(qǐng)求缀皱，并收到客戶的應(yīng)答后，即斷開連接动猬；HTTP的短連接和長連接是指TCP的短連接和長連接啤斗，從HTTP角度看其實(shí)是無連接的

HTTPS協(xié)議（443端口）

• 作用：解決了http的安全問題

  • http使用明文進(jìn)行通信，內(nèi)容可能會(huì)被竊聽赁咙；https則是加密通信

  • http不驗(yàn)證通信方的身份钮莲，通信方的身份有可能遭遇偽裝免钻；https則有身份驗(yàn)證

  • http無法證明報(bào)文的完整性，報(bào)文有可能遭篡改臂痕；https有報(bào)文摘要

• 本質(zhì)

  • HTTPS 并不是新協(xié)議伯襟，而是讓 HTTP 先和 SSL（Secure Sockets Layer）通信協(xié)商加密使用的對(duì)稱加密密鑰，再由 SSL 和 TCP 通信

  • https采用混合加密：使用非對(duì)稱密鑰加密方式握童，傳輸對(duì)稱密鑰加密方式所需要的 Secret Key姆怪，從而保證安全性；獲取到 Secret Key 后澡绩，再使用對(duì)稱密鑰加密方式進(jìn)行通信稽揭，從而保證效率

• 對(duì)稱加密 vs 非對(duì)稱加密

  • 對(duì)稱密鑰加密：

    • 加密和解密使用同一密鑰

    • AES：設(shè)AES加密函數(shù)為E，則 C = E(K, P),其中P為明文肥卡，K為密鑰溪掀，C為密文；設(shè)AES解密函數(shù)為D步鉴，則 P = D(K, C),其中C為密文揪胃，K為密鑰，P為明文氛琢；AES為分組密碼喊递，分組密碼也就是把明文分成一組一組的，每組長度相等阳似，每次加密一組數(shù)據(jù)骚勘，直到加密完整個(gè)明文

  • 非對(duì)稱密鑰加密：

    • 通信發(fā)送方獲得接收方的公開密鑰之后，就可以使用公開密鑰進(jìn)行加密撮奏，接收方收到通信內(nèi)容后使用私有密鑰解密

    • 通信發(fā)送方使用其私有密鑰進(jìn)行簽名俏讹，通信接收方使用發(fā)送方的公開密鑰對(duì)簽名進(jìn)行解密，就能判斷這個(gè)簽名是否正確

    • RSA加密通過生成密文【密文=明文^e mod N】畜吊，其中（N泽疆，e）是您的公鑰，解密通過【明文=密文^d mod N】其中（N玲献，d）是私鑰

  • 為什么RSA（非對(duì)稱加密）比AES（對(duì)稱加密）慢

    • RSA主要慢在解密過程于微，因?yàn)樗借€很長

    • RSA有冪模運(yùn)算，AES主要是異或青自、移位等運(yùn)算

• 數(shù)字證書

  • 數(shù)字證書認(rèn)證機(jī)構(gòu)（CA株依，Certificate Authority）是客戶端與服務(wù)器雙方都可信賴的第三方機(jī)構(gòu)

  • 服務(wù)器的運(yùn)營人員向 CA 提出公開密鑰的申請(qǐng)，CA 在判明提出申請(qǐng)者的身份之后延窜，會(huì)對(duì)用自己的私鑰已申請(qǐng)的公開密鑰做數(shù)字簽名恋腕，做成證書

  • 進(jìn)行 HTTPS 通信時(shí)，服務(wù)器會(huì)把證書發(fā)送給客戶端逆瑞≤伲客戶端取得其中的公開密鑰之后伙单，用CA的公鑰對(duì)數(shù)字簽名進(jìn)行驗(yàn)證，如果驗(yàn)證通過哈肖，就可以開始通信了

• SSL握手過程

  • 客戶端向服務(wù)端發(fā)送：隨機(jī)數(shù)A吻育；支持的加密算法與摘要算法

  • 服務(wù)端向客戶端發(fā)送：選擇的加密算法與摘要算法；數(shù)字證書（含服務(wù)端的公鑰）淤井；隨機(jī)數(shù)B

  • 客戶端驗(yàn)證服務(wù)器的合法性：用CA的公鑰解開數(shù)字證書進(jìn)行驗(yàn)證布疼，并得到服務(wù)端公鑰

  • 客戶端向服務(wù)端發(fā)送：用服務(wù)端公鑰加密的隨機(jī)數(shù)C（并且計(jì)算出對(duì)稱加密的公鑰K=f(A,B,C)）

  • 服務(wù)端接收到信息后，用自己的私鑰解密得到C币狠，并且計(jì)算出對(duì)稱加密的公鑰K=f(A,B,C)

• 報(bào)文摘要

  • 發(fā)送方：用哈希函數(shù)將報(bào)文明文生成報(bào)文摘要游两；將摘要用私鑰加密；同時(shí)發(fā)送明文和加密后的摘要

  • 接收方：用哈希函數(shù)將報(bào)文明文生成報(bào)文摘要1漩绵；用公鑰將摘要解密贱案，獲取摘要2；比較摘要1和2

• http如何轉(zhuǎn)為https

  • 302 跳轉(zhuǎn)

    • 服務(wù)端把所有的 HTTP 流量跳轉(zhuǎn)到 HTTPS 上

    • 有安全漏洞：第一次訪問站點(diǎn)的時(shí)候如果是 HTTP 就有可能被中間人劫持止吐，很可能都沒到 302 跳轉(zhuǎn)的時(shí)候就被劫持了

  • HSTS機(jī)制

    • 支持 HSTS 的服務(wù)端宝踪，可以強(qiáng)制訪問它的瀏覽器使用 HTTPS 協(xié)議

    • 用戶的瀏覽器一旦得到了 HSTS 的信息，下次再訪問站點(diǎn)的時(shí)候客戶端瀏覽器就會(huì)強(qiáng)制使用 HTTPS

    • 這樣就解釋了為什么我們使用主流瀏覽器輸入網(wǎng)站域名的時(shí)候碍扔，都會(huì)自動(dòng)跳轉(zhuǎn)到 HTTPS 了：因?yàn)槲覀冊(cè)L問的大多是主流的大網(wǎng)站

    • 缺點(diǎn)

      • 假如用戶的瀏覽器從未訪問過這個(gè)站點(diǎn)瘩燥，這個(gè)時(shí)候依然會(huì)有被劫持風(fēng)險(xiǎn)

      • 如果你的站點(diǎn)的 HTTPS 服務(wù)沒有完全準(zhǔn)備好，不要輕易的開啟 HSTS 響應(yīng)頭蕴忆。因?yàn)橐坏g覽器得到這個(gè)響應(yīng)頭颤芬，就會(huì)在規(guī)定的 max-age 的時(shí)間段內(nèi)強(qiáng)制使用 HTTPS 訪問悲幅，如果你的服務(wù)沒準(zhǔn)備好套鹅，用戶就會(huì)一直訪問失敗，并且不能降級(jí)

RIP協(xié)議

• 應(yīng)用層協(xié)議

• 每個(gè)路由器維護(hù)一張表汰具，記錄該路由器到其它網(wǎng)絡(luò)的”跳數(shù)“卓鹿，路由器到與其直接連接的網(wǎng)絡(luò)的跳數(shù)是1，每多經(jīng)過一個(gè)路由器跳數(shù)就加1留荔；更新該表時(shí)和相鄰路由器交換路由信息吟孙；路由器允許一個(gè)路徑最多包含15個(gè)路由器，如果跳數(shù)為16聚蝶，則不可達(dá)杰妓。交付數(shù)據(jù)報(bào)時(shí)優(yōu)先選取距離最短的路徑

一些常用端口

• FTP(21端口)：文件傳輸協(xié)議

• SSH(22端口)：遠(yuǎn)程登陸

• DNS(53端口)：域名解析

• HTTP 80

• HTTPS 443

接口限流

計(jì)數(shù)器算法

• 限制一秒鐘的能夠通過的請(qǐng)求數(shù)，比如限流qps為100碘勉，算法的實(shí)現(xiàn)思路就是從第一個(gè)請(qǐng)求進(jìn)來開始計(jì)時(shí)巷挥，在接下去的1s內(nèi)，每來一個(gè)請(qǐng)求验靡，就把計(jì)數(shù)加1倍宾，如果累加的數(shù)字達(dá)到了100雏节，那么后續(xù)的請(qǐng)求就會(huì)被全部拒絕

• 有一個(gè)弊端：如果我在單位時(shí)間1s內(nèi)的前10ms，已經(jīng)通過了100個(gè)請(qǐng)求高职，那后面的990ms钩乍，只能眼巴巴的把請(qǐng)求拒絕，我們把這種現(xiàn)象稱為“突刺現(xiàn)象”

漏桶算法

• 處理的速度是固定的怔锌，請(qǐng)求進(jìn)來的速度是未知的寥粹，可能突然進(jìn)來很多請(qǐng)求，沒來得及處理的請(qǐng)求就先放在桶里产禾，既然是個(gè)桶排作，肯定是有容量上限，如果桶滿了亚情，那么新進(jìn)來的請(qǐng)求就丟棄

• 在算法實(shí)現(xiàn)方面妄痪，可以準(zhǔn)備一個(gè)隊(duì)列，用來保存請(qǐng)求楞件，另外通過一個(gè)線程池定期從隊(duì)列中獲取請(qǐng)求并執(zhí)行衫生，可以一次性獲取多個(gè)并發(fā)執(zhí)行

• 存在弊端：無法應(yīng)對(duì)短時(shí)間的突發(fā)流量

令牌桶算法

• 存在一個(gè)桶，用來存放固定數(shù)量的令牌土浸。算法中存在一種機(jī)制罪针，以一定的速率往桶中放令牌。每次請(qǐng)求調(diào)用需要先獲取令牌黄伊，只有拿到令牌泪酱，才有機(jī)會(huì)繼續(xù)執(zhí)行，否則選擇選擇等待可用的令牌还最、或者直接拒絕

• 如果桶中令牌數(shù)達(dá)到上限墓阀，就丟棄令牌

• 可以準(zhǔn)備一個(gè)隊(duì)列，用來保存令牌拓轻，另外通過一個(gè)線程池定期生成令牌放到隊(duì)列中斯撮，每來一個(gè)請(qǐng)求，就從隊(duì)列中獲取一個(gè)令牌扶叉，并繼續(xù)執(zhí)行

網(wǎng)絡(luò)攻擊

DNS劫持

• 現(xiàn)象：輸入的網(wǎng)址是 http://www.google.com勿锅，出來的是百度的頁面

• 解決方法：修改DNS服務(wù)器為一個(gè)更可靠的服務(wù)器；在host文件中記錄域名到ip的映射

HTTP劫持

• 現(xiàn)象：打開一個(gè)頁面枣氧，右下角彈出廣告

• 解決方法：https（加密+認(rèn)證+報(bào)文摘要）

SSL劫持

• 過程：攻擊者將自己偽裝成客戶端溢十，獲取到服務(wù)器真實(shí)有效的 CA 證書（非對(duì)稱加密的公鑰）；將自己偽裝成服務(wù)器达吞，獲取到客戶端的之后通信的密鑰（對(duì)稱加密的密鑰）张弛；有了證書和密鑰就可以監(jiān)聽之后通信的內(nèi)容了

• 解決方法：客戶端不要輕易信任證書；提前預(yù)埋證書在本地

SSL剝離

• 過程：攻擊者利用用戶對(duì)于地址欄中HTTPS與HTTP的疏忽，將所有的HTTPS連接都用HTTP來代替乌庶；同時(shí)种蝶，與目標(biāo)服務(wù)器建立正常的HTTPS連接，受攻擊客戶端與原始請(qǐng)求服務(wù)器之間的全部通信經(jīng)過了攻擊者的轉(zhuǎn)發(fā)

• 解決方法：客戶端使用https瞒大；使用HSTS機(jī)制

SYN洪泛攻擊

• 過程：攻擊者發(fā)送大量TCP SYN報(bào)文段螃征，而不完成第三次握手，服務(wù)器不斷為這些半開連接分配資源（TCP每建立一個(gè)連接都要分配資源：一些變量透敌、發(fā)送/接收緩存等）盯滚，導(dǎo)致服務(wù)器的連接資源被耗盡

• 解決方法：

  • 服務(wù)器接收到SYN報(bào)文段時(shí)，不會(huì)建立半開連接酗电，而是生成一個(gè)初始TCP序列號(hào)x魄藕，并發(fā)送以x為序列號(hào)的SYNACK分組

  • 只有收到確認(rèn)號(hào)為x+1的ACK報(bào)文段，才會(huì)建立全連接（即完成了三次握手）

ARP欺騙

• 過程：攻擊者發(fā)送ARP包撵术，其中IP地址到MAC地址的映射是錯(cuò)誤的

• 解決方法：把映射寫死

反向代理 vs 正向代理

正向代理

• 客戶端代理背率，服務(wù)端不知道實(shí)際發(fā)起請(qǐng)求的客戶端

• 比如我們國內(nèi)訪問谷歌，直接訪問訪問不到嫩与，我們可以通過一個(gè)正向代理服務(wù)器寝姿，請(qǐng)求發(fā)到代理，代理服務(wù)器能夠訪問谷歌划滋，這樣由代理去谷歌取到返回?cái)?shù)據(jù)饵筑，再返回給我們，這樣我們就能訪問谷歌了

• 條件GET請(qǐng)求

  • 為避免代理服務(wù)器中存的數(shù)據(jù)已過期处坪，web緩存器（即代理服務(wù)器）每次都會(huì)向源服務(wù)器發(fā)送條件GET請(qǐng)求（在請(qǐng)求報(bào)文中有if-modified-since）根资，僅當(dāng)自指定日期之后該對(duì)象被修改過，源服務(wù)器才會(huì)發(fā)送該對(duì)象給web緩存器

• 作用

  • 訪問原來無法訪問的資源

  • 可以做緩存同窘，加速訪問資源

  • 對(duì)客戶端訪問授權(quán)玄帕，上網(wǎng)進(jìn)行認(rèn)證

  • 代理可以記錄用戶訪問記錄（上網(wǎng)行為管理），對(duì)外隱藏用戶信息

反向代理

• 以代理服務(wù)器來接受internet上的連接請(qǐng)求塞椎，然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器桨仿，并將從服務(wù)器上得到的結(jié)果返回給internet上請(qǐng)求連接的客戶端睛低，此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)服務(wù)器

• 服務(wù)端代理案狠，客戶端不知道實(shí)際提供服務(wù)的服務(wù)端

• 作用

  • 保證內(nèi)網(wǎng)的安全，阻止web攻擊钱雷，大型網(wǎng)站骂铁，通常將反向代理作為公網(wǎng)訪問地址，Web服務(wù)器是內(nèi)網(wǎng)

  • 負(fù)載均衡罩抗，通過反向代理服務(wù)器來優(yōu)化網(wǎng)站的負(fù)載

MSS vs MTU

MSS

• 最大報(bào)文段長度

• TCP可從緩存中取出并放入報(bào)文段中的最大數(shù)據(jù)數(shù)量

• MSS<=MTU-TCP首部長度（因?yàn)橐ＷC一個(gè)TCP報(bào)文段可以裝進(jìn)幀中）

MTU

• 最大傳輸單元

• 最大鏈路層幀長度

斷點(diǎn)續(xù)傳

含義

將一個(gè)文件按照一定的規(guī)則人為的分割成多個(gè)小文件拉庵，然后客戶端每次只上傳一個(gè)小文件（當(dāng)然我們也可以利用多線程技術(shù)每次上傳多個(gè)小文件），服務(wù)器接收到上傳過來的小文件后根據(jù)一定的規(guī)則來組合這些小文件套蒂。如果在上傳過程中出現(xiàn)網(wǎng)絡(luò)中斷等意外情況钞支，下次再次上傳時(shí)可以從已經(jīng)上傳的部分繼續(xù)上傳茫蛹，而不是重新上傳

實(shí)現(xiàn)

• 在 http報(bào)文頭部 里添加兩個(gè)參數(shù)：客戶端請(qǐng)求時(shí)發(fā)送的 Range 和服務(wù)器返回信息時(shí)返回的 Content-Range，Range 用于指定第一個(gè)字節(jié)和最后一個(gè)字節(jié)的位置

• http響應(yīng)狀態(tài)行會(huì)有“partial content”字樣

• 如果在客戶端請(qǐng)求報(bào)文頭中烁挟，對(duì) Range 填入了錯(cuò)誤的范圍值婴洼，服務(wù)器會(huì)返回 416 狀態(tài)碼

如何判斷服務(wù)器是否支持?jǐn)帱c(diǎn)續(xù)傳

• 判斷服務(wù)端是否只 HTTP/1.1 及以上版本，如果是則支持?jǐn)帱c(diǎn)續(xù)傳撼嗓，如果不是則不支持

• 服務(wù)端返回響應(yīng)的頭部是否包含 Access-Ranges 柬采，且參數(shù)內(nèi)容是 bytes

當(dāng)服務(wù)器端的文件發(fā)生改變時(shí)，客戶端再次向服務(wù)端發(fā)送斷點(diǎn)續(xù)傳請(qǐng)求且警，如何處理

• 法一：最后修改時(shí)間

  • 先前服務(wù)器發(fā)送給了客戶端一個(gè) Last-Modified 時(shí)間

  • 客戶端把這個(gè)時(shí)間 寫入if-Modified-Since粉捻，發(fā)給服務(wù)器

  • 服務(wù)器進(jìn)行最后修改時(shí)間驗(yàn)證后，告知客戶端是否需要重新從服務(wù)器端獲取新內(nèi)容

  • 服務(wù)器返回狀態(tài)碼 206 代表不需要重新獲取接著下載就行斑芜，200代表需要重新獲取

• 法二：版本號(hào)

  • 法一存在的問題

    • 某些文件只是修改了修改時(shí)間而內(nèi)容卻沒變肩刃，這時(shí)我們并不希望客戶端重新緩存這些文件

    • 某些文件修改頻繁，有時(shí)一秒要修改十幾次杏头，但是 if-Modified-Since 是秒級(jí)的

    • 部分服務(wù)器無法獲得精確的修改時(shí)間

  • 使用etag：文件版本號(hào)

  • 如果etag沒有發(fā)生改變服務(wù)器將向客戶端發(fā)送剩余的部分树酪，否則發(fā)送全部

秒傳

將文件的MD5發(fā)送給服務(wù)器，服務(wù)器根據(jù)傳輸過來的MD5判斷服務(wù)器上是否存在相同類型的文件大州，如果存在就將文件復(fù)制一份续语，而不是本地上傳

服務(wù)端如何處理多個(gè)客戶端的socket

每有一個(gè)Socket請(qǐng)求的時(shí)候，就從線程池中取一個(gè)線程來處理這個(gè)請(qǐng)求

線程池的好處

• 線程復(fù)用厦画，創(chuàng)建線程耗時(shí)疮茄，回收線程慢

• 防止短時(shí)間內(nèi)高并發(fā)，指定線程池大小根暑，超過數(shù)量將等待力试，方式短時(shí)間創(chuàng)建大量線程導(dǎo)致資源耗盡，服務(wù)掛掉