计算机网络基础必备（三次握手，四次握手，以及HTTP协议相关）
目錄
- 一、計(jì)算機(jī)網(wǎng)絡(luò)
- 通信協(xié)議
- 網(wǎng)絡(luò)模型
- 二、TCP/IP
- TCP/IP 與 HTTP
- TCP 與 UDP
- TCP連接的建立與終止
- TCP報(bào)文首部
- TCP 三次握手
- TCP 四次揮手
- 四個(gè)計(jì)時(shí)器
- 保持計(jì)時(shí)器：
- 時(shí)間等待計(jì)時(shí)器：
- 重傳計(jì)時(shí)器
- 堅(jiān)持計(jì)時(shí)器
- TCP協(xié)議如何來保證傳輸?shù)目煽啃?/li>
- 滑動(dòng)窗口機(jī)制
- 流量控制
- 擁塞控制
- TCP的擁塞處理
- 服務(wù)器出現(xiàn)了大量CLOSE_WAIT狀態(tài)如何解決
- 講一講SYN超時(shí)，洪泛攻擊，以及解決策略
- 三、HTTP
- URI 和 URL
- HTTP消息的結(jié)構(gòu)
- HTTP事務(wù)：
- 報(bào)文：
- 方法
- Get與POST的區(qū)別
- 狀態(tài)碼
- 協(xié)議版本
- 四、HTTPS
- HTTP和HTTPS對(duì)比
- 對(duì)稱加密與非對(duì)稱加密
- 共享密鑰加密(對(duì)稱秘鑰加密)
- 公開密鑰（非對(duì)稱密鑰）
- SSL/TSL
- 證書
- HTTPS的工作原理
- HTTPS的優(yōu)點(diǎn)
- HTTPS的缺點(diǎn)
- HTTP 切換到 HTTPS
- 什么是Cookie，Cookie的使用過程是怎么樣的？
- 什么是session，有哪些實(shí)現(xiàn)session的機(jī)制？
- session和cookie有什么區(qū)別
- Other FAQ
- 從輸入網(wǎng)址到獲得頁面的過程
- XSS 攻擊
- IP地址的分類
- XSS 攻擊
- IP地址的分類
或許你會(huì)碰到這些問題
瀏覽器中輸入一個(gè) URL 至頁面呈現(xiàn)，網(wǎng)絡(luò)上都發(fā)生了什么事？
能說說 ISO 七層模型和 TCP/IP 四層模型嗎？
TCP/IP 與 HTTP 有什么關(guān)系嗎？
TCP協(xié)議與UDP協(xié)議的區(qū)別？
請(qǐng)?jiān)敿?xì)介紹一下 TCP 的三次握手機(jī)制，為什么要三次握手？揮手卻又是四次呢？
詳細(xì)講一下TCP的滑動(dòng)窗口？知道流量控制和擁塞控制嗎？
說一下對(duì)稱加密與非對(duì)稱加密？
狀態(tài)碼 206 是什么意思？
你們用的 https 是吧，https 工作原理是什么？
…
那么對(duì)于這些問題，你又是如何回答的呢。
一、計(jì)算機(jī)網(wǎng)絡(luò)
通信協(xié)議
通信協(xié)議（communications protocol）是指雙方實(shí)體完成通信或服務(wù)所必須遵循的規(guī)則和約定。通過通信信道和設(shè)備互連起來的多個(gè)不同地理位置的數(shù)據(jù)通信系統(tǒng)，要使其能協(xié)同工作實(shí)現(xiàn)信息交換和資源共享，它們之間必須具有共同的語言。交流什么、怎樣交流及何時(shí)交流，都必須遵循某種互相都能接受的規(guī)則。這個(gè)規(guī)則就是通信協(xié)議。
網(wǎng)絡(luò)模型
隨著技術(shù)的發(fā)展，計(jì)算機(jī)的應(yīng)用越來越廣泛，計(jì)算機(jī)之間的通信開始了百花齊放的狀態(tài)，每個(gè)具有獨(dú)立計(jì)算服務(wù)體系的信息技術(shù)公司都會(huì)建立自己的計(jì)算機(jī)通信規(guī)則，而這種情況會(huì)導(dǎo)致異構(gòu)計(jì)算機(jī)之間無法通信，極大的阻礙了網(wǎng)絡(luò)通信的發(fā)展，至此為了解決這個(gè)問題，國(guó)際標(biāo)準(zhǔn)化組織（ISO）制定了OSI模型，該模型定義了不同計(jì)算機(jī)互聯(lián)的標(biāo)準(zhǔn)，OSI模型把網(wǎng)絡(luò)通信的工作分為7層，分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層和應(yīng)用層。
這七層模型是設(shè)計(jì)層面的概念，每一層都有固定要完成的職責(zé)和功能，分層的好處在于清晰和功能獨(dú)立性，但分層過多會(huì)使層次變的更加復(fù)雜，雖然不需要實(shí)現(xiàn)本層的功能，但是也需要構(gòu)造本層的上下文，空耗系統(tǒng)資源，所以在落地實(shí)施網(wǎng)絡(luò)通信模型的時(shí)候?qū)⑦@七層模型簡(jiǎn)化合并為四層模型分別是應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、網(wǎng)絡(luò)接口層（各層之間的模型、協(xié)議統(tǒng)稱為：TCP/IP協(xié)議簇）。
從上圖可以看到，TCP/IP模型合并了OSI模型的應(yīng)用層、表示層和會(huì)話層，將OSI模型的數(shù)據(jù)鏈路層和物理層合并為網(wǎng)絡(luò)訪問層。
上圖還列出了各層模型對(duì)應(yīng)TCP/IP協(xié)議棧中的協(xié)議以及各層協(xié)議之間的關(guān)系。比如DNS協(xié)議是建立在TCP和UDP協(xié)議的基礎(chǔ)上，FTP、HTTP、TELNET協(xié)議建立在TCP協(xié)議的基礎(chǔ)上，NTP、TFTP、SNMP建立在UDP協(xié)議的基礎(chǔ)上，而TCP、UDP協(xié)議又建立在IP協(xié)議的基礎(chǔ)上，以此類推….
| 應(yīng)用層 | 文件傳輸，電子郵件，文件服務(wù)，虛擬終端 | TFTP，HTTP，SNMP，FTP，SMTP，DNS，RIP，Telnet |
| 表示層 | 數(shù)據(jù)格式化，代碼轉(zhuǎn)換，數(shù)據(jù)加密 | 無 |
| 會(huì)話層 | 控制應(yīng)用程序之間會(huì)話能力；如不同軟件數(shù)據(jù)分發(fā)給不同軟件 | ASAP、TLS、SSH、ISO 8327 / CCITT X.225、RPC、NetBIOS、ASP、Winsock、BSD sockets |
| 傳輸層 | 端到端傳輸數(shù)據(jù)的基本功能 | TCP、UDP |
| 網(wǎng)絡(luò)層 | 定義IP編址，定義路由功能；如不同設(shè)備的數(shù)據(jù)轉(zhuǎn)發(fā) | IP，ICMP，RIP，OSPF，BGP，IGMP |
| 數(shù)據(jù)鏈路層 | 定義數(shù)據(jù)的基本格式，如何傳輸，如何標(biāo)識(shí) | SLIP，CSLIP，PPP，ARP，RARP，MTU |
| 物理層 | 以二進(jìn)制數(shù)據(jù)形式在物理媒體上傳輸數(shù)據(jù) | ISO2110，IEEE802 |
當(dāng)我們某一個(gè)網(wǎng)站上不去的時(shí)候。通常會(huì)ping一下這個(gè)網(wǎng)站
ping 可以說是ICMP的最著名的應(yīng)用，是TCP/IP協(xié)議的一部分。利用ping命令可以檢查網(wǎng)絡(luò)是否連通，可以很好地幫助我們分析和判定網(wǎng)絡(luò)故障。
二、TCP/IP
數(shù)據(jù)在網(wǎng)絡(luò)中傳輸最終一定是通過物理介質(zhì)傳輸。物理介質(zhì)就是把電腦連接起來的物理手段，常見的有光纖、雙絞線，以及無線電波，它決定了電信號(hào)(0和1)的傳輸方式，物理介質(zhì)的不同決定了電信號(hào)的傳輸帶寬、速率、傳輸距離以及抗干擾性等等。網(wǎng)絡(luò)數(shù)據(jù)傳輸就像快遞郵寄，數(shù)據(jù)就是快件。只有路打通了，你的”快遞”才能送到，因此物理介質(zhì)是網(wǎng)絡(luò)通信的基石。
寄快遞首先得稱重、確認(rèn)體積(確認(rèn)數(shù)據(jù)大小)，貴重物品還得層層包裹填充物確保安全，封裝，然后填寫發(fā)件地址(源主機(jī)地址)和收件地址(目標(biāo)主機(jī)地址)，確認(rèn)快遞方式。對(duì)于偏遠(yuǎn)地區(qū)，快遞不能直達(dá)，還需要中途轉(zhuǎn)發(fā)。網(wǎng)絡(luò)通信也是一樣的道理，只不過把這些步驟都規(guī)定成了各種協(xié)議。
TCP/IP的模型的每一層都需要下一層所提供的協(xié)議來完成自己的目的。我們來看下數(shù)據(jù)是怎么通過TCP/IP協(xié)議模型從一臺(tái)主機(jī)發(fā)送到另一臺(tái)主機(jī)的。
當(dāng)用戶通過HTTP協(xié)議發(fā)起一個(gè)請(qǐng)求，應(yīng)用層、傳輸層、網(wǎng)絡(luò)互聯(lián)層和網(wǎng)絡(luò)訪問層的相關(guān)協(xié)議依次對(duì)該請(qǐng)求進(jìn)行包裝并攜帶對(duì)應(yīng)的首部，最終在網(wǎng)絡(luò)訪問層生成以太網(wǎng)數(shù)據(jù)包，以太網(wǎng)數(shù)據(jù)包通過物理介質(zhì)傳輸給對(duì)方主機(jī)，對(duì)方接收到數(shù)據(jù)包以后，然后再一層一層采用對(duì)應(yīng)的協(xié)議進(jìn)行拆包，最后把應(yīng)用層數(shù)據(jù)交給應(yīng)用程序處理。
TCP/IP 與 HTTP
TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協(xié)議/網(wǎng)際協(xié)議）是指能夠在多個(gè)不同網(wǎng)絡(luò)間實(shí)現(xiàn)信息傳輸?shù)膮f(xié)議簇。TCP/IP 協(xié)議不僅僅指的是 TCP 和 IP 兩個(gè)協(xié)議，而是指一個(gè)由FTP、SMTP、TCP、UDP、IP等協(xié)議構(gòu)成的協(xié)議簇， 只是因?yàn)樵赥CP/IP協(xié)議中TCP協(xié)議和IP協(xié)議最具代表性，所以被稱為TCP/IP協(xié)議。
而HTTP是應(yīng)用層協(xié)議，主要解決如何包裝數(shù)據(jù)。
“IP”代表網(wǎng)際協(xié)議，TCP 和 UDP 使用該協(xié)議從一個(gè)網(wǎng)絡(luò)傳送數(shù)據(jù)包到另一個(gè)網(wǎng)絡(luò)。把IP想像成一種高速公路，它允許其它協(xié)議在上面行駛并找到到其它電腦的出口。TCP和UDP是高速公路上的“卡車”，它們攜帶的貨物就是像HTTP，文件傳輸協(xié)議FTP這樣的協(xié)議等。
TCP 與 UDP
都屬于傳輸層協(xié)議。
TCP（Transmission Control Protocol，傳輸控制協(xié)議）是面向連接的協(xié)議，也就是說，在收發(fā)數(shù)據(jù)前，必須和對(duì)方建立可靠的連接。一個(gè)TCP連接必須有三次握手、四次揮手。
UDP（User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議）是一個(gè)非連接的協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接， 當(dāng)它想傳送時(shí)就簡(jiǎn)單地去抓取來自應(yīng)用程序的數(shù)據(jù)，并盡可能快地把它扔到網(wǎng)絡(luò)上
| 連接性 | 面向連接 | 面向非連接 |
| 傳輸可靠性 | 可靠 | 不可靠 |
| 報(bào)文 | 面向字節(jié)流 | 面向報(bào)文 |
| 效率 | 傳輸效率低 | 傳輸效率高 |
| 流量控制 | 滑動(dòng)窗口 | 無 |
| 擁塞控制 | 慢開始、擁塞避免、快重傳、快恢復(fù) | 無 |
| 傳輸速度 | 慢 | 快 |
| 應(yīng)用場(chǎng)合 | 對(duì)效率要求低，對(duì)準(zhǔn)確性要求高或要求有連接的場(chǎng)景 | 對(duì)效率要求高，對(duì)準(zhǔn)確性要求低 |
TCP和UDP協(xié)議的一些應(yīng)用
TCP連接的建立與終止
TCP雖然是面向字節(jié)流的，但TCP傳送的數(shù)據(jù)單元卻是報(bào)文段。一個(gè)TCP報(bào)文段分為首部和數(shù)據(jù)兩部分，而TCP的全部功能體現(xiàn)在它首部中的各字段的作用。
TCP報(bào)文段首部的前20個(gè)字節(jié)是固定的（下圖），后面有4n字節(jié)是根據(jù)需要而增加的選項(xiàng)（n是整數(shù)）。因此TCP首部的最小長(zhǎng)度是20字節(jié)。
TCP報(bào)文首部
-
源端口和目的端口，各占2個(gè)字節(jié)，分別寫入源端口和目的端口；
-
序列號(hào)（Sequence number），占4字節(jié)。序號(hào)范圍是【0，2^32 - 1】，共2^32個(gè)序號(hào)。序號(hào)增加到 2^32-1后，下一個(gè)序號(hào)就又回到 0。TCP是面向字節(jié)流的。在一個(gè)TCP連接中傳送的字節(jié)流中的每一個(gè)字節(jié)都按順序編號(hào)。整個(gè)要傳送的字節(jié)流的起始序號(hào)必須在連接建立時(shí)設(shè)置。首部中的序號(hào)字段值則是指的是本報(bào)文段所發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)。例如，一報(bào)文段的序號(hào)是301，而接待的數(shù)據(jù)共有100字節(jié)。這就表明：本報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)是301，最后一個(gè)字節(jié)的序號(hào)是400。顯然，下一個(gè)報(bào)文段（如果還有的話）的數(shù)據(jù)序號(hào)應(yīng)當(dāng)從401開始，即下一個(gè)報(bào)文段的序號(hào)字段值應(yīng)為401。這個(gè)字段的序號(hào)也叫“報(bào)文段序號(hào)”;
-
確認(rèn)號(hào)（Acknowledge number），占4個(gè)字節(jié)，是期望收到對(duì)方下一個(gè)報(bào)文的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)。例如，B收到了A發(fā)送過來的報(bào)文，其序列號(hào)字段是501，而數(shù)據(jù)長(zhǎng)度是200字節(jié)，這表明B正確的收到了A發(fā)送的到序號(hào)700為止的數(shù)據(jù)。因此，B期望收到A的下一個(gè)數(shù)據(jù)序號(hào)是701，于是B在發(fā)送給A的確認(rèn)報(bào)文段中把確認(rèn)號(hào)置為701；
-
數(shù)據(jù)偏移，占4位，它指出TCP報(bào)文段的數(shù)據(jù)起始處距離TCP報(bào)文段的起始處有多遠(yuǎn)。
-
保留，占6位，保留為今后使用，但目前應(yīng)置為0；
-
緊急URG（URGent），當(dāng)URG=1，表明緊急指針字段有效。告訴系統(tǒng)此報(bào)文段中有緊急數(shù)據(jù)；
-
確認(rèn)ACK（ACKnowledgment），僅當(dāng)ACK=1時(shí)，確認(rèn)號(hào)字段才有效。TCP規(guī)定，在連接建立后所有報(bào)文的傳輸都必須把ACK置1；
-
推送PSH（PuSH） ，當(dāng)兩個(gè)應(yīng)用進(jìn)程進(jìn)行交互式通信時(shí)，有時(shí)在一端的應(yīng)用進(jìn)程希望在鍵入一個(gè)命令后立即就能收到對(duì)方的響應(yīng)，這時(shí)候就將PSH=1；
-
復(fù)位RST（ReSeT），當(dāng)RST=1，表明TCP連接中出現(xiàn)嚴(yán)重差錯(cuò)，必須釋放連接，然后再重新建立連接；
-
同步SYN（SYNchronization），在連接建立時(shí)用來同步序號(hào)。當(dāng)SYN=1，ACK=0，表明是連接請(qǐng)求報(bào)文，若同意連接，則響應(yīng)報(bào)文中應(yīng)該使SYN=1，ACK=1；
-
終止FIN（FINis），用來釋放連接。當(dāng)FIN=1，表明此報(bào)文的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并且要求釋放；
-
- 窗口，占2字節(jié)，指的是通知接收方，發(fā)送本報(bào)文你需要有多大的空間來接受；
-
檢驗(yàn)和，占2字節(jié)，校驗(yàn)首部和數(shù)據(jù)這兩部分；
-
緊急指針，占2字節(jié)，指出本報(bào)文段中的緊急數(shù)據(jù)的字節(jié)數(shù)；
-
選項(xiàng)，長(zhǎng)度可變，定義一些其他的可選的參數(shù)
TCP是一種面向連接的單播協(xié)議，在發(fā)送數(shù)據(jù)前，通信雙方必須在彼此間建立一條連接。所謂的“連接”，其實(shí)是客戶端和服務(wù)器的內(nèi)存里保存的一份關(guān)于對(duì)方的信息，如ip地址、端口號(hào)等。
接下來通過這張圖熟悉一下
TCP 三次握手
所謂三次握手(Three-way Handshake)，是指建立一個(gè) TCP 連接時(shí)，需要客戶端和服務(wù)器總共發(fā)送3個(gè)包。
三次握手的目的是連接服務(wù)器指定端口，建立 TCP 連接，并同步連接雙方的序列號(hào)和確認(rèn)號(hào)，交換 TCP 窗口大小信息。
TCP連接建立需要經(jīng)過“三次握手"(there way handshake)。這個(gè)過程可以描述如下。
-
第一次握手(同步SYN=1, 連接請(qǐng)求報(bào)文seq=x)
(1)最初的客戶端TCP進(jìn)程是處于CLOSE(關(guān)閉)狀態(tài)。當(dāng)客戶端準(zhǔn)備發(fā)起一次TCP連接，進(jìn)人SYN-SEND(準(zhǔn)備發(fā)送)狀態(tài)時(shí)，它首先向處于LISTEN(收聽)狀態(tài)的服務(wù)器端CP進(jìn)程發(fā)送第一個(gè)控制位SYN=1的“連接建立請(qǐng)求報(bào)文”。“連接建立請(qǐng)求報(bào)文"不攜帶數(shù)據(jù)字段，但是需要給報(bào)文一個(gè)序號(hào),圖中標(biāo)為“SYN=1,seq=x"。
需要注意的是:“連接建立請(qǐng)求報(bào)文”的序號(hào)seq 值x是隨機(jī)產(chǎn)生的，但是不能為0。隨機(jī)數(shù)x不能為0的理由是:避免因TCP連接非正常斷開而可能引起的混亂。如果在連接突然中斷時(shí)，可能有一個(gè)或兩個(gè)進(jìn)程同時(shí)等待對(duì)方的確認(rèn)應(yīng)答.而這個(gè)時(shí)候有一個(gè)新連接的建立連接。
序號(hào)也是從0開始，那么接收進(jìn)程就有可能認(rèn)為是對(duì)方重傳的報(bào)文，這樣就有可能造成連接過程的錯(cuò)誤。為了避免可能引起的問題，協(xié)議規(guī)定SYN報(bào)文序號(hào)seq值I必須隨機(jī)產(chǎn)生，并且不能為0,
? 客戶端發(fā)送連接請(qǐng)求報(bào)文段，這是報(bào)文首部中的同步位SYN=1，同時(shí)選擇一個(gè)初始序列號(hào) seq=x ，此時(shí)，客戶端進(jìn)程進(jìn)入了 SYN-SENT（同步已發(fā)送狀態(tài)）狀態(tài)。TCP規(guī)定，SYN報(bào)文段（SYN=1的報(bào)文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個(gè)序號(hào)；
-
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)
? 服務(wù)器端在接收到“連接建立請(qǐng)求報(bào)文”之后， 如果同意建立連接，則向客戶端發(fā)送第二個(gè)控制位SYN=1、ACK=1的“連接建立請(qǐng)求確認(rèn)報(bào)文”。確認(rèn)號(hào)ack=x+1,表示是對(duì)第一個(gè)“連接建立請(qǐng)求報(bào)文”(序號(hào)seq=x)的確認(rèn)。同樣，“連接建立請(qǐng)求確認(rèn)報(bào)文"不攜帶數(shù)據(jù)字段，但是需要給報(bào)文一個(gè)序號(hào)(seq=y)。圖中標(biāo)為“SYN= 1,ACK= l,seq=y,ack=x+1"。這時(shí)服務(wù)器進(jìn)人SYN-RCVD(準(zhǔn)備接收)狀態(tài)。
? 服務(wù)器收到客戶端的SYN報(bào)文段，如果同意連接，則發(fā)出確認(rèn)報(bào)文。確認(rèn)報(bào)文中應(yīng)該 ACK=1，SYN=1，確認(rèn)號(hào)ACKnum=x+1，同時(shí)，自己還要發(fā)送SYN請(qǐng)求信息，SYN=1，為自己初始化一個(gè)序列號(hào) seq=y，服務(wù)器端將上述所有信息放到一個(gè)報(bào)文段（即SYN+ACK報(bào)文段）中，一并發(fā)送給客戶端，此時(shí)，TCP服務(wù)器進(jìn)程進(jìn)入了SYN-RCVD（同步收到）狀態(tài)。這個(gè)報(bào)文也不能攜帶數(shù)據(jù)，但是同樣要消耗一個(gè)序號(hào)
-
第三次握手(ACK=1，ACKnum=y+1)
? 在接收到“連接建立請(qǐng)求確認(rèn)報(bào)文”之后，客戶端發(fā)送第三個(gè)控制位ACK=1"連接建立請(qǐng)求確認(rèn)報(bào)文”。由于該報(bào)文是對(duì)“連接建立請(qǐng)求確認(rèn)報(bào)文”(序號(hào)seq=:y)的確認(rèn)，因此確認(rèn)序號(hào)ack=y+1。同樣，“連接建立請(qǐng)求確認(rèn)報(bào)文”不攜帶數(shù)據(jù)字段。但是需要給報(bào)文一個(gè)序號(hào)。按照TCP協(xié)議規(guī)定，這個(gè)“連接建立請(qǐng)求確認(rèn)報(bào)文”的序號(hào)仍然為x十1.圖中標(biāo)為“ACK= 1,seq=x+1 ,ack=y+1"。這時(shí)客戶端進(jìn)入ESTABLISHED(已建立連接)狀態(tài)。
? 客戶端收到服務(wù)器的SYN+ACK報(bào)文段，再次發(fā)送確認(rèn)包(ACK)，SYN 標(biāo)志位為0，ACK 標(biāo)志位為1，確認(rèn)號(hào) ACKnum = y+1，這個(gè)報(bào)文段發(fā)送完畢以后，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED（已建立連接）狀態(tài)，完成TCP三次握手。
為什么需要三次握手呢？兩次不行嗎？
為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤。
具體例子：“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒有要求建立連接。”
TCP 四次揮手
TCP 的連接的拆除需要發(fā)送四個(gè)包，因此稱為四次揮手(Four-way handshake)，也叫做改進(jìn)的三次握手。客戶端或服務(wù)器均可主動(dòng)發(fā)起揮手動(dòng)作。
-
第一次揮手(FIN=1，seq=x)
(1)當(dāng)客戶準(zhǔn)備各結(jié)束一次數(shù)據(jù)傳輸，主動(dòng)提出釋放TCP連接時(shí)，進(jìn)入FIN-WAIT-1(釋放等待-1)狀態(tài)。它向服服務(wù)器端發(fā)送第一個(gè)控制位FIN=1的“連接釋放請(qǐng)求報(bào)文”，接出連接釋放清求，停止發(fā)送數(shù)據(jù)。“連接釋放請(qǐng)求報(bào)文"不攜帶數(shù)據(jù)字段。但是需要給報(bào)文一個(gè)序號(hào)
圖中標(biāo)為FIN=1，seq=u"”。 “u“等于客戶端發(fā)送的最后一個(gè)字節(jié)的序號(hào)加1，
主機(jī)1（可以使客戶端，也可以是服務(wù)器端），設(shè)置seq=x，向主機(jī)2發(fā)送一個(gè)FIN報(bào)文段；此時(shí)，主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)；這表示主機(jī)1沒有數(shù)據(jù)要發(fā)送給主機(jī)2了；
-
第二次揮手(ACK=1，ACKnum=x+1)
(2)服務(wù)器在接收到“連接釋放請(qǐng)求報(bào)文”之后，需要向客戶發(fā)回“連接釋放請(qǐng)求確認(rèn)報(bào)文”，表示對(duì)接收第一個(gè)連接釋放請(qǐng)求報(bào)文的確認(rèn)，因此ack =u+1。這個(gè)“連接釋放請(qǐng)求報(bào)文”的序號(hào)為V等于服務(wù)器發(fā)送的最后一個(gè)字節(jié)序號(hào)加1。圖中標(biāo)為“ACK= l,seq=t，ack=u+1".
TCP服務(wù)器進(jìn)程向高層應(yīng)用進(jìn)程通知客戶請(qǐng)求釋放TCP連接,客戶到服務(wù)器的TCP連接斷開。但是，服務(wù)器到客戶的TCP連接還沒有斷開，如果服務(wù)器還有數(shù)據(jù)報(bào)文需要發(fā)送時(shí)，它還可以繼續(xù)發(fā)送直至完畢。這種狀態(tài)稱為半關(guān)閉(helf-close)狀態(tài)。這個(gè)狀態(tài)需要持續(xù)一段時(shí)間。客戶在接收到服務(wù)器發(fā)送的ACK報(bào)文之后進(jìn)人FIN-WAIT-2狀態(tài):服務(wù)器進(jìn)入CLOSE WAIT狀態(tài)。
? 主機(jī)2收到了主機(jī)1發(fā)送的FIN報(bào)文段，向主機(jī)1回一個(gè)ACK報(bào)文段，Acknnum=x+1，主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)；主機(jī)2告訴主機(jī)1，我“同意”你的關(guān)閉請(qǐng)求；
-
第三次揮手(FIN=1，seq=y)
(3)服務(wù)器的高層應(yīng)用程序已經(jīng)沒有數(shù)據(jù)需要發(fā)送時(shí)，它會(huì)通知TCP可以釋放法地這時(shí)服務(wù)器向客戶發(fā)送“連接釋放請(qǐng)求報(bào)文”。這個(gè)“連接釋放請(qǐng)求報(bào)文”的序號(hào)取決干大業(yè)關(guān)閉狀態(tài)時(shí)，服務(wù)器端是否發(fā)送過數(shù)據(jù)報(bào)文。因此序號(hào)假定為w。圖中標(biāo)為“FIN=1ACK=1,seq=w,ack=u+1”。服務(wù)器端經(jīng)過LAST-ACK狀態(tài)之后轉(zhuǎn)回到LISTENC聽)狀態(tài)。
主機(jī)2向主機(jī)1發(fā)送FIN報(bào)文段，請(qǐng)求關(guān)閉連接，同時(shí)主機(jī)2進(jìn)入LAST_ACK 狀態(tài)
-
第四次揮手(ACK=1，ACKnum=y+1)
(4)客戶在接收到FIN報(bào)文之后向服務(wù)器發(fā)送“連接釋放請(qǐng)求確認(rèn)報(bào)文”報(bào)文,表示對(duì)服務(wù)器"連接釋放請(qǐng)求報(bào)文”的確認(rèn)。圖中ACK報(bào)文記為“ACK=1,seu+l,ack=w+1”。
主機(jī)1收到主機(jī)2發(fā)送的FIN報(bào)文段，向主機(jī)2發(fā)送ACK報(bào)文段，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài)；主機(jī)2收到主機(jī)1的ACK報(bào)文段以后，就關(guān)閉連接；此時(shí)，主機(jī)1等待2MSL后依然沒有收到回復(fù)，則證明Server端已正常關(guān)閉，那好，主機(jī)1也可以關(guān)閉連接了，進(jìn)入 CLOSED 狀態(tài)。
主機(jī) 1 等待了某個(gè)固定時(shí)間（兩個(gè)最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，沒有收到服務(wù)器端的 ACK ，認(rèn)為服務(wù)器端已經(jīng)正常關(guān)閉連接，于是自己也關(guān)閉連接，進(jìn)入 CLOSED 狀態(tài)。
為什么連接的時(shí)候是三次握手，關(guān)閉的時(shí)候卻是四次握手？
因?yàn)楫?dāng)Server端收到Client端的SYN連接請(qǐng)求報(bào)文后，可以直接發(fā)送SYN+ACK報(bào)文。其中ACK報(bào)文是用來應(yīng)答的，SYN報(bào)文是用來同步的。但是關(guān)閉連接時(shí)，當(dāng)Server端收到FIN報(bào)文時(shí)，很可能并不會(huì)立即關(guān)閉SOCKET，所以只能先回復(fù)一個(gè)ACK報(bào)文，告訴Client端，“你發(fā)的FIN報(bào)文我收到了”。只有等到我Server端所有的報(bào)文都發(fā)送完了，我才能發(fā)送FIN報(bào)文，因此不能一起發(fā)送。故需要四步握手。
由于 TCP 協(xié)議是全雙工的，也就是說客戶端和服務(wù)端都可以發(fā)起斷開連接。兩邊各發(fā)起一次斷開連接的申請(qǐng)，加上各自的兩次確認(rèn)，看起來就像執(zhí)行了四次揮手。
為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報(bào)文段生存時(shí)間)才能返回到CLOSE狀態(tài)？
雖然按道理，四個(gè)報(bào)文都發(fā)送完畢，我們可以直接進(jìn)入CLOSE狀態(tài)了，但是我們必須假象網(wǎng)絡(luò)是不可靠的，有可以最后一個(gè)ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報(bào)文。
還有一個(gè)原因，防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請(qǐng)求報(bào)文段”出現(xiàn)在本連接中。客戶端發(fā)送完最后一個(gè)確認(rèn)報(bào)文后，在這個(gè)2MSL時(shí)間中，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣新的連接中不會(huì)出現(xiàn)舊連接的請(qǐng)求報(bào)文。
四個(gè)計(jì)時(shí)器
保持計(jì)時(shí)器：
為了保證TCP工作正常、有序地進(jìn)行，TCP設(shè)置了保持計(jì)時(shí)器(keep timer),用來防止TCP連接處以長(zhǎng)時(shí)期空閑。如果客戶端建立到服務(wù)器端的連接,傳輸一此數(shù)據(jù)，然后停止傳輸，可能是這個(gè)客戶端出故障。在這種情況下，這個(gè)連接將永遠(yuǎn)處于打開狀態(tài)。為了解決這種問題，一般是在服務(wù)器端設(shè)置保持計(jì)時(shí)器。當(dāng)服務(wù)器端收到客戶端的報(bào)文時(shí)，就將保持計(jì)時(shí)器復(fù)位。如果服務(wù)器端過了設(shè)定的時(shí)間沒有收到客戶端的信息，它就發(fā)送探測(cè)報(bào)文。如果發(fā)送10個(gè)探測(cè)報(bào)文(每一個(gè)相隔75s)還沒有響應(yīng)，就假設(shè)客戶端出現(xiàn)故障，進(jìn)而終止該連接。
時(shí)間等待計(jì)時(shí)器：
為了保證TCP連接釋放過程正常地進(jìn)行.TCP設(shè)置了時(shí)間等待計(jì)時(shí)器(TIME waITTimer)。當(dāng)TCP關(guān)閉一個(gè)連接時(shí)，它并不認(rèn)為這個(gè)連接馬上就真正地關(guān)閉。這時(shí),客戶端進(jìn)入TIME-WAIT狀態(tài),需要再等待兩個(gè)最長(zhǎng)報(bào)文壽命(maximum segment lfetime,MSL)時(shí)間之后,才真正進(jìn)人CLOSE(關(guān)閉)狀態(tài)。
客戶端與服務(wù)器端經(jīng)過“四次握手”之后，確認(rèn)雙方已經(jīng)同意釋放連接,客戶端仍然需要采取延遲2MSL時(shí)間,確保服務(wù)器在最后階段發(fā)送給客戶端的數(shù)據(jù),以及客戶端發(fā)送給服務(wù)器的最后一個(gè)ACK報(bào)文都能正確地被接收防止因個(gè)別報(bào)文傳輸錯(cuò)誤導(dǎo)致連接釋放失敗。
重傳計(jì)時(shí)器
TCP使用重傳計(jì)時(shí)器(retransmission timer)來控制報(bào)文確認(rèn)與等待重傳的時(shí)間，當(dāng)發(fā)送端TCP發(fā)送一個(gè)報(bào)文時(shí)，首先將它的一個(gè)報(bào)文的副本放人重傳隊(duì)列，同時(shí)啟動(dòng)一個(gè)面?zhèn)饔?jì)時(shí)器。重傳計(jì)時(shí)器設(shè)定一個(gè)值，例如400ms,然后開始倒計(jì)時(shí)。在重傳計(jì)時(shí)器倒計(jì)時(shí)到0之前收到確認(rèn)，表示該報(bào)文傳輸成功;如果在計(jì)時(shí)器倒計(jì)時(shí)到0之時(shí)沒收到確認(rèn)，表示該報(bào)文傳輸失敗.準(zhǔn)備重傳該報(bào)文。
堅(jiān)持計(jì)時(shí)器
在執(zhí)行滑動(dòng)窗口控制的過程中.要求發(fā)送端在接收到零窗口通告之后就停止發(fā)送，這個(gè)過程直到接收端的TCP再發(fā)出一個(gè)非零窗口通告為止。但是，如果下一個(gè)非零窗口通告丟失，那么發(fā)送端將無休止地等待接收端的通知，這就會(huì)造成死鎖。為防止非零窗口通知丟失造成“死鎖”的現(xiàn)象出現(xiàn),TCP設(shè)置了一個(gè)“堅(jiān)持計(jì)時(shí)器"(persistence timer)。
當(dāng)發(fā)送端的TCP收到一個(gè)零窗口通知時(shí)，就啟動(dòng)堅(jiān)持計(jì)時(shí)器。當(dāng)堅(jiān)持計(jì)時(shí)器時(shí)間到，發(fā)送端的TCP就發(fā)送一個(gè)零窗口探測(cè)報(bào)文。這個(gè)報(bào)文只有一個(gè)字節(jié)的數(shù)據(jù),它有一個(gè)序號(hào),但它的序號(hào)不需要確認(rèn)。零窗口探測(cè)報(bào)文的作用是提示接收端:非零窗口通知丟失，必須重傳。
堅(jiān)持計(jì)時(shí)器的值設(shè)置為重傳時(shí)間的數(shù)值，最大為60秒。如果發(fā)出的第一個(gè)零窗口探測(cè)報(bào)文沒有收到應(yīng)答，則需發(fā)送第二個(gè)零窗口探測(cè)報(bào)文，直到收到非零窗口為止。
TCP協(xié)議如何來保證傳輸?shù)目煽啃?/h3>
對(duì)于可靠性，TCP通過以下方式進(jìn)行保證：
- 數(shù)據(jù)包校驗(yàn)：目的是檢測(cè)數(shù)據(jù)在傳輸過程中的任何變化，若校驗(yàn)出包有錯(cuò)，則丟棄報(bào)文段并且不給出響應(yīng)，這時(shí)TCP發(fā)送數(shù)據(jù)端超時(shí)后會(huì)重發(fā)數(shù)據(jù)；
- 對(duì)失序數(shù)據(jù)包重排序：既然TCP報(bào)文段作為IP數(shù)據(jù)報(bào)來傳輸，而IP數(shù)據(jù)報(bào)的到達(dá)可能會(huì)失序，因此TCP報(bào)文段的到達(dá)也可能會(huì)失序。TCP將對(duì)失序數(shù)據(jù)進(jìn)行重新排序，然后才交給應(yīng)用層；
- 丟棄重復(fù)數(shù)據(jù)：對(duì)于重復(fù)數(shù)據(jù)，能夠丟棄重復(fù)數(shù)據(jù)；
- 應(yīng)答機(jī)制：當(dāng)TCP收到發(fā)自TCP連接另一端的數(shù)據(jù)，它將發(fā)送一個(gè)確認(rèn)。這個(gè)確認(rèn)不是立即發(fā)送，通常將推遲幾分之一秒；
- 超時(shí)重發(fā)：當(dāng)TCP發(fā)出一個(gè)段后，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段；
- 流量控制：TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出，這就是流量控制。TCP使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。
詳細(xì)講一下TCP的滑動(dòng)窗口
滑動(dòng)窗口機(jī)制
如果發(fā)送方把數(shù)據(jù)發(fā)送得過快，接收方可能會(huì)來不及接收，這就會(huì)造成數(shù)據(jù)的丟失。所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來得及接收。
利用滑動(dòng)窗口機(jī)制可以很方便地在TCP連接上實(shí)現(xiàn)對(duì)發(fā)送方的流量控制。
從上面的圖可以看到滑動(dòng)窗口左邊的是已發(fā)送并且被確認(rèn)的分組，滑動(dòng)窗口右邊是還沒有輪到的分組。滑動(dòng)窗口里面也分為兩塊，一塊是已經(jīng)發(fā)送但是未被確認(rèn)的分組，另一塊是窗口內(nèi)等待發(fā)送的分組。隨著已發(fā)送的分組不斷被確認(rèn)，窗口內(nèi)等待發(fā)送的分組也會(huì)不斷被發(fā)送。整個(gè)窗口就會(huì)往右移動(dòng)，讓還沒輪到的分組進(jìn)入窗口內(nèi)。
可以看到滑動(dòng)窗口起到了一個(gè)限流的作用，也就是說當(dāng)前滑動(dòng)窗口的大小決定了當(dāng)前 TCP 發(fā)送包的速率，而滑動(dòng)窗口的大小取決于擁塞控制窗口和流量控制窗口的兩者間的最小值。
流量控制
TCP 是全雙工的客戶端和服務(wù)器均可作為發(fā)送方或接收方，我們現(xiàn)在假設(shè)一個(gè)發(fā)送方向接收方發(fā)送數(shù)據(jù)的場(chǎng)景來講解流量控制。首先我們的接收方有一塊接收緩存，當(dāng)數(shù)據(jù)來到時(shí)會(huì)先把數(shù)據(jù)放到緩存中，上層應(yīng)用等緩存中有數(shù)據(jù)時(shí)就會(huì)到緩存中取數(shù)據(jù)。假如發(fā)送方?jīng)]有限制地不斷地向接收方發(fā)送數(shù)據(jù)，接收方的應(yīng)用程序又沒有及時(shí)把接收緩存中的數(shù)據(jù)讀走，就會(huì)出現(xiàn)緩存溢出，數(shù)據(jù)丟失的現(xiàn)象，為了解決這個(gè)問題，我們引入流量控制窗口。
假設(shè)應(yīng)用程序最后讀走的數(shù)據(jù)序號(hào)是 lastByteRead，接收緩存中接收到的最后一個(gè)數(shù)據(jù)序號(hào)是 lastByteRcv，接收緩存的大小為 RcvSize，那么必須要滿足 lastByteRcv - lastByteRead <= RcvSize 才能保證接收緩存不會(huì)溢出，所以我們定義流量窗口為接收緩存剩余的空間，也就是Rcv = RcvSize - (lastByteRcv - lastByteRead)。只要接收方在響應(yīng) ACK 的時(shí)候把這個(gè)窗口的值帶給發(fā)送方，發(fā)送方就能知道接收方的接收緩存還有多大的空間，進(jìn)而設(shè)置滑動(dòng)窗口的大小。
擁塞控制
擁塞控制是指發(fā)送方先設(shè)置一個(gè)小的窗口值作為發(fā)送速率，當(dāng)成功發(fā)包并接收到ACK時(shí)，便以指數(shù)速率增大發(fā)送窗口的大小，直到遇到丟包（超時(shí)/三個(gè)冗余ACK），才停止并調(diào)整窗口的大小。這么做能最大限度地利用帶寬，又不至于讓網(wǎng)絡(luò)環(huán)境變得太過擁擠。
最終滑動(dòng)窗口的值將設(shè)置為流量控制窗口和擁塞控制窗口中的較小值。
TCP的擁塞處理
計(jì)算機(jī)網(wǎng)絡(luò)中的帶寬、交換結(jié)點(diǎn)中的緩存及處理機(jī)等都是網(wǎng)絡(luò)的資源。在某段時(shí)間，若對(duì)網(wǎng)絡(luò)中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就會(huì)變壞，這種情況就叫做擁塞。擁塞控制就是防止過多的數(shù)據(jù)注入網(wǎng)絡(luò)中，這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不致過載。注意，擁塞控制和流量控制不同，前者是一個(gè)全局性的過程，而后者指點(diǎn)對(duì)點(diǎn)通信量的控制。擁塞控制的方法主要有以下四種：
服務(wù)器出現(xiàn)了大量CLOSE_WAIT狀態(tài)如何解決
大量 CLOSE_WAIT 表示程序出現(xiàn)了問題，對(duì)方的 socket 已經(jīng)關(guān)閉連接，而我方忙于讀或?qū)憶]有及時(shí)關(guān)閉連接，需要檢查代碼，特別是釋放資源的代碼，或者是處理請(qǐng)求的線程配置。
講一講SYN超時(shí)，洪泛攻擊，以及解決策略
什么 SYN 是洪泛攻擊？在 TCP 的三次握手機(jī)制的第一步中，客戶端會(huì)向服務(wù)器發(fā)送 SYN 報(bào)文段。服務(wù)器接收到 SYN 報(bào)文段后會(huì)為該TCP分配緩存和變量，如果攻擊分子大量地往服務(wù)器發(fā)送 SYN 報(bào)文段，服務(wù)器的連接資源終將被耗盡，導(dǎo)致內(nèi)存溢出無法繼續(xù)服務(wù)。
解決策略：當(dāng)服務(wù)器接受到 SYN 報(bào)文段時(shí)，不直接為該 TCP 分配資源，而只是打開一個(gè)半開的套接字。接著會(huì)使用 SYN 報(bào)文段的源Id，目的Id，端口號(hào)以及只有服務(wù)器自己知道的一個(gè)秘密函數(shù)生成一個(gè) cookie，并把 cookie 作為序列號(hào)響應(yīng)給客戶端。
如果客戶端是正常建立連接，將會(huì)返回一個(gè)確認(rèn)字段為 cookie + 1 的報(bào)文段。接下來服務(wù)器會(huì)根據(jù)確認(rèn)報(bào)文的源Id，目的Id，端口號(hào)以及秘密函數(shù)計(jì)算出一個(gè)結(jié)果，如果結(jié)果的值 + 1等于確認(rèn)字段的值，則證明是剛剛請(qǐng)求連接的客戶端，這時(shí)候才為該 TCP 分配資源
這樣一來就不會(huì)為惡意攻擊的 SYN 報(bào)文段分配資源空間，避免了攻擊。
三、HTTP
HTTP1.0、HTTP1.1、HTTP2.0 的區(qū)別
post 和 get 的區(qū)別
HTTP全稱是 HyperText Transfer Protocal，即：超文本傳輸協(xié)議。是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)通信協(xié)議，它允許將超文本標(biāo)記語言（HTML）文檔從Web服務(wù)器傳送到客戶端的瀏覽器。目前我們使用的是HTTP/1.1 版本。所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。1960年美國(guó)人 Ted Nelson 構(gòu)思了一種通過計(jì)算機(jī)處理文本信息的方法，并稱之為超文本（hypertext），這成為了HTTP超文本傳輸協(xié)議標(biāo)準(zhǔn)架構(gòu)的發(fā)展根基。
URI 和 URL
每個(gè)Web 服務(wù)器資源都有一個(gè)名字，這樣客戶端就可以說明他們感興趣的資源是什么了，服務(wù)器資源名被稱為統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifier,URI）。URI 就像因特網(wǎng)上的郵政地址一樣，在世界范圍內(nèi)唯一標(biāo)識(shí)并定位信息資源。
統(tǒng)一資源定位符（URL）是資源標(biāo)識(shí)符最常見的形式。URL 描述了一臺(tái)特定服務(wù)器上某資源的特定位置。
現(xiàn)在幾乎所有的 URI 都是 URL。
URI 的第二種形式就是統(tǒng)一資源名（URN）。URN 是作為特定內(nèi)容的唯一名稱使用的，與目前的資源所在地?zé)o關(guān)。
HTTP消息的結(jié)構(gòu)
事務(wù)和報(bào)文
客戶端是怎樣通過HTTP與Web服務(wù)器及其資源進(jìn)行事務(wù)處理的呢？一個(gè)HTTP事務(wù)由一條請(qǐng)求命令（從客戶端發(fā)往服務(wù)器）和一個(gè)響應(yīng)（從服務(wù)器發(fā)回客戶端）結(jié)果組成。這種通信是通過名為HTTP報(bào)文（HTTP Message）的格式化數(shù)據(jù)塊進(jìn)行的。
HTTP事務(wù)：
報(bào)文：
HTTP 報(bào)文是純文本，不是二進(jìn)制代碼。從 Web 客戶端發(fā)往 Web 服務(wù)器的 HTTP 報(bào)文稱為請(qǐng)求報(bào)文（request message）。從服務(wù)器發(fā)往客戶端的報(bào)文稱為響應(yīng)報(bào)文。
HTTP 報(bào)文包括三部分：
- 起始行
- 首部字段
- 主體
方法
Http協(xié)議定義了很多與服務(wù)器交互的方法，最基本的有4種，分別是GET,POST,PUT,DELETE. 一個(gè)URL地址用于描述一個(gè)網(wǎng)絡(luò)上的資源，而HTTP中的GET, POST, PUT, DELETE就對(duì)應(yīng)著對(duì)這個(gè)資源的查，改，增，刪4個(gè)操作。我們最常見的就是GET和POST了。GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息。
- GET
- HEAD
- PUT
- POST
- TRACE
- OPTIONS
- DELETE
Get與POST的區(qū)別
GET與POST是我們常用的兩種HTTP Method，二者之間的區(qū)別主要包括如下五個(gè)方面：
HTTP請(qǐng)求結(jié)構(gòu)：請(qǐng)求方式 + 請(qǐng)求URI + 協(xié)議及其版本
HTTP響應(yīng)結(jié)構(gòu)：狀態(tài)碼 + 原因短語 + 協(xié)議及其版本
狀態(tài)碼
每條HTTP響應(yīng)報(bào)文返回時(shí)都會(huì)攜帶一個(gè)狀態(tài)碼。狀態(tài)碼是一個(gè)三位數(shù)字的代碼，告知客戶端請(qǐng)求是否成功，或者是都需要采取其他動(dòng)作。
- 1xx：表明服務(wù)端接收了客戶端請(qǐng)求，客戶端繼續(xù)發(fā)送請(qǐng)求；
- 2xx：客戶端發(fā)送的請(qǐng)求被服務(wù)端成功接收并成功進(jìn)行了處理；
- 3xx：服務(wù)端給客戶端返回用于重定向的信息；
- 4xx：客戶端的請(qǐng)求有非法內(nèi)容；
- 5xx：服務(wù)端未能正常處理客戶端的請(qǐng)求而出現(xiàn)意外錯(cuò)誤。
- 200 OK：表示從客戶端發(fā)送給服務(wù)器的請(qǐng)求被正常處理并返回；
- 204 No Content：表示客戶端發(fā)送給客戶端的請(qǐng)求得到了成功處理，但在返回的響應(yīng)報(bào)文中不含實(shí)體的主體部分（沒有資源可以返回）
- 206 Patial Content：表示客戶端進(jìn)行了范圍請(qǐng)求，并且服務(wù)器成功執(zhí)行了這部分的GET請(qǐng)求，響應(yīng)報(bào)文中包含由Content-Range指定范圍的實(shí)體內(nèi)容。
- 301 Moved Permanently：永久性重定向，表示請(qǐng)求的資源被分配了新的URL，之后應(yīng)使用更改的URL；
- 302 Found：臨時(shí)性重定向，表示請(qǐng)求的資源被分配了新的URL，希望本次訪問使用新的URL；
- 303 See Other：表示請(qǐng)求的資源被分配了新的URL，應(yīng)使用GET方法定向獲取請(qǐng)求的資源
- 304 Not Modified：表示客戶端發(fā)送附帶條件（是指采用GET方法的請(qǐng)求報(bào)文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的請(qǐng)求時(shí)，服務(wù)器端允許訪問資源，但是請(qǐng)求為滿足條件的情況下返回改狀態(tài)碼；
- 400 Bad Request:表示請(qǐng)求報(bào)文中存在語法錯(cuò)誤；
- 401 Unauthorized：經(jīng)許可，需要通過HTTP認(rèn)證；
- 403 Forbidden：服務(wù)器拒絕該次訪問（訪問權(quán)限出現(xiàn)問題）
- 404 Not Found：表示服務(wù)器上無法找到請(qǐng)求的資源，除此之外，也可以在服務(wù)器拒絕請(qǐng)求但不想給拒絕原因時(shí)使用；
- 500 Inter Server Error：表示服務(wù)器在執(zhí)行請(qǐng)求時(shí)發(fā)生了錯(cuò)誤，也有可能是web應(yīng)用存在的bug或某些臨時(shí)的錯(cuò)誤時(shí)；
- 503 Server Unavailable：表示服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，無法處理請(qǐng)求；
HTTP 是個(gè)應(yīng)用層協(xié)議。HTTP 無需操心網(wǎng)絡(luò)通信的具體細(xì)節(jié)，而是把這些細(xì)節(jié)都交給了通用可靠的因特網(wǎng)傳輸協(xié)議 TCP/IP。
在 HTTP 客戶端向服務(wù)器發(fā)送報(bào)文之前，需要用網(wǎng)絡(luò)協(xié)議（Internet Protocol，IP）地址和端口號(hào)在客戶端和服務(wù)器之間建立一條 TCP/IP 協(xié)議。而 IP 地址就是通過 URL 提供的，像 http://207.200.21.11:80/index.html，還有使用域名服務(wù)（Domain Name Services，DNS）的 http://www.lazyegg.net。
協(xié)議版本
-
HTTP/0.9
HTTP協(xié)議的最初版本，功能簡(jiǎn)陋，僅支持 GET 方法，并且僅能請(qǐng)求訪問 HTML 格式的資源
-
HTTP/1.0
-
- 增加了請(qǐng)求方式 POST 和 HEAD
- 不再局限于0.9版本的HTML格式，根據(jù)Content-Type可以支持多種數(shù)據(jù)格式，即MIME多用途互聯(lián)網(wǎng)郵件擴(kuò)展，例如text/html、image/jpeg等
- 同時(shí)也開始支持 cache，就是當(dāng)客戶端在規(guī)定時(shí)間內(nèi)訪問統(tǒng)一網(wǎng)站，直接訪問cache即可
- HTTP請(qǐng)求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分，每次通信都必須包括頭信息（HTTP header），用來描述一些元數(shù)據(jù)。其他的新增功能還包括狀態(tài)碼（status code）、多字符集支持、多部分發(fā)送（multi-part type）、權(quán)限（authorization）、緩存（cache）、內(nèi)容編碼（content encoding）等
- 但是1.0版本的工作方式是每次TCP連接只能發(fā)送一個(gè)請(qǐng)求，當(dāng)服務(wù)器響應(yīng)后就會(huì)關(guān)閉這次連接，下一個(gè)請(qǐng)求需要再次建立TCP連接，就是不支持keepalive
-
HTTP/1.0+
在20世紀(jì)90年代中葉，為滿足飛快發(fā)展的萬維網(wǎng)，很多流行的 Web 客戶端和服務(wù)器飛快的向 HTTP 中添加各種特性，包括持久的 keep-alive 連接、虛擬主機(jī)支持，以及代理連接支持都被假如到 HTTP 中，并稱為非官方的事實(shí)標(biāo)準(zhǔn)。這種非正式的 HTTP 擴(kuò)展版本通常稱為 HTTP/1.0+
-
HTTP/1.1
-
- http1.1是目前最為主流的http協(xié)議版本，從1997年發(fā)布至今，仍是主流的http協(xié)議版本。
- 引入了持久連接，或叫長(zhǎng)連接（ persistent connection），即TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請(qǐng)求復(fù)用，不用聲明Connection: keep-alive。
- 引入了管道機(jī)制（ pipelining），即在同一個(gè)TCP連接里，客戶端可以同時(shí)發(fā)送多個(gè)請(qǐng)求，進(jìn)一步改進(jìn)了HTTP協(xié)議的效率。
- 新增方法：PUT、 PATCH、 OPTIONS、 DELETE。
- http協(xié)議不帶有狀態(tài)，每次請(qǐng)求都必須附上所有信息。請(qǐng)求的很多字段都是重復(fù)的，浪費(fèi)帶寬，影響速度。
-
HTTP/2.0（又名 HTTP-NG）
-
- http/2發(fā)布于2015年，目前應(yīng)用還比較少。
- http/2是一個(gè)徹底的二進(jìn)制協(xié)議，頭信息和數(shù)據(jù)體都是二進(jìn)制，并且統(tǒng)稱為"幀"（frame）：頭信息幀和數(shù)據(jù)幀。
- 復(fù)用TCP連接，在一個(gè)連接里，客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng)，且不用按順序一一對(duì)應(yīng)，避免了隊(duì)頭堵塞的問題,此雙向的實(shí)時(shí)通信稱為多工（ Multiplexing）。
- HTTP/2 允許服務(wù)器未經(jīng)請(qǐng)求，主動(dòng)向客戶端發(fā)送資源，即服務(wù)器推送。
- 引入頭信息壓縮機(jī)制（ header compression） ,頭信息使用gzip或compress壓縮后再發(fā)送。
四、HTTPS
HTTP缺點(diǎn)：
因此，HTTP協(xié)議不適合傳輸一些敏感信息，比如：信用卡號(hào)、密碼等支付信息。
為了解決HTTP協(xié)議的這一缺陷，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議 HTTPS，為了數(shù)據(jù)傳輸?shù)陌踩?#xff0c;HTTPS在HTTP的基礎(chǔ)上加入了SSL（安全套接層）協(xié)議，SSL依靠證書來驗(yàn)證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的通信加密。
與 SSL（安全套接層）組合使用的 HTTP 就是 HTTPS
img
HTTP和HTTPS對(duì)比
HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網(wǎng)景公司設(shè)計(jì)了SSL（Secure Sockets Layer）協(xié)議用于對(duì)HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密，從而就誕生了HTTPS。簡(jiǎn)單來說，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全。
HTTPS和HTTP的區(qū)別主要如下：
對(duì)稱加密與非對(duì)稱加密
主要的加密方法分為兩種：一種是共享密鑰加密（對(duì)稱密鑰加密），一種是公開密鑰加密（非對(duì)稱密鑰加密）
共享密鑰加密(對(duì)稱秘鑰加密)
加密與解密使用同一個(gè)密鑰，常見的對(duì)稱加密算法：DES，AES，3DES等。
img
也就是說在加密的同時(shí)，也會(huì)把密鑰發(fā)送給對(duì)方。在發(fā)送密鑰過程中可能會(huì)造成密鑰被竊取，那么如何解決這一問題呢？
公開密鑰（非對(duì)稱密鑰）
公開密鑰使用一對(duì)非對(duì)稱密鑰。一把叫私有密鑰，另一把叫公開密鑰。私有密鑰不讓任何人知道，公有密鑰隨意發(fā)送。公鑰加密的信息，只有私鑰才能解密。常見的非對(duì)稱加密算法：RSA，ECC等。
也就是說，發(fā)送密文方使用對(duì)方的公開密鑰進(jìn)行加密，對(duì)方接受到信息后，使用私有密鑰進(jìn)行解密。
對(duì)稱加密加密與解密使用的是同樣的密鑰，所以速度快，但由于需要將密鑰在網(wǎng)絡(luò)傳輸，所以安全性不高。
非對(duì)稱加密使用了一對(duì)密鑰，公鑰與私鑰，所以安全性高，但加密與解密速度慢。
為了解決這一問題，https采用對(duì)稱加密與非對(duì)稱加密的混合加密方式。
SSL/TSL
SSL（Secure Sockets Layer），中文叫做“安全套接層”。它是在上世紀(jì)90年代中期，由網(wǎng)景公司設(shè)計(jì)的。
SSL 協(xié)議就是用來解決 HTTP 傳輸過程的不安全問題，到了1999年，SSL 因?yàn)閼?yīng)用廣泛，已經(jīng)成為互聯(lián)網(wǎng)上的事實(shí)標(biāo)準(zhǔn)。IETF 就在那年把 SSL 標(biāo)準(zhǔn)化。標(biāo)準(zhǔn)化之后的名稱改為 TLS（是“Transport Layer Security”的縮寫），中文叫做“傳輸層安全協(xié)議”。
很多相關(guān)的文章都把這兩者并列稱呼（SSL/TLS），因?yàn)檫@兩者可以視作同一個(gè)東西的不同階段。
SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。
但是，這里有兩個(gè)問題。
- 如何保證公鑰不被篡改？
解決方法：將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的。
-
公鑰加密計(jì)算量太大，如何減少耗用的時(shí)間？
每一次對(duì)話（session），客戶端和服務(wù)器端都生成一個(gè)"對(duì)話密鑰"（session key），用它來加密信息。由于"對(duì)話密鑰"是對(duì)稱加密，所以運(yùn)算速度非常快，而服務(wù)器公鑰只用于加密"對(duì)話密鑰"本身，這樣就減少了加密運(yùn)算的消耗時(shí)間。
因此，SSL/TLS協(xié)議的基本過程是這樣的：
HTTPS相比HTTP，在請(qǐng)求前多了一個(gè)「握手」的環(huán)節(jié)。
握手過程中確定了數(shù)據(jù)加密的密碼。在握手過程中，網(wǎng)站會(huì)向?yàn)g覽器發(fā)送 SSL 證書，SSL 證書和我們?nèi)粘Ｓ玫纳矸葑C類似，是一個(gè)支持 HTTPS 網(wǎng)站的身份證明，SSL 證書里面包含了網(wǎng)站的域名，證書有效期，證書的頒發(fā)機(jī)構(gòu)以及用于加密傳輸密碼的公鑰等信息，由于公鑰加密的密碼只能被在申請(qǐng)證書時(shí)生成的私鑰解密，因此瀏覽器在生成密碼之前需要先核對(duì)當(dāng)前訪問的域名與證書上綁定的域名是否一致，同時(shí)還要對(duì)證書的頒發(fā)機(jī)構(gòu)進(jìn)行驗(yàn)證，如果驗(yàn)證失敗瀏覽器會(huì)給出證書錯(cuò)誤的提示。
證書
實(shí)際上，我們使用的證書分很多種類型，SSL證書只是其中的一種。證書的格式是由 X.509 標(biāo)準(zhǔn)定義。SSL 證書負(fù)責(zé)傳輸公鑰，是一種PKI（Public Key Infrastructure，公鑰基礎(chǔ)結(jié)構(gòu)）證書。
我們常見的證書根據(jù)用途不同大致有以下幾種：
這些證書都是由受認(rèn)證的證書頒發(fā)機(jī)構(gòu)——我們稱之為CA（Certificate Authority）機(jī)構(gòu)來頒發(fā)，針對(duì)企業(yè)與個(gè)人的不同，可申請(qǐng)的證書的類型也不同，價(jià)格也不同。CA機(jī)構(gòu)頒發(fā)的證書都是受信任的證書，對(duì)于 SSL 證書來說，如果訪問的網(wǎng)站與證書綁定的網(wǎng)站一致就可以通過瀏覽器的驗(yàn)證而不會(huì)提示錯(cuò)誤。
為什么服務(wù)端要發(fā)送證書給客戶端
互聯(lián)網(wǎng)有太多的服務(wù)需要使用證書來驗(yàn)證身份，以至于客戶端(操作系統(tǒng)或?yàn)g覽器等)無法內(nèi)置所有證書，需要通過服務(wù)端將證書發(fā)送給客戶端。
客戶端為什么要驗(yàn)證接收到的證書
中間人攻擊
客戶端<------------攻擊者<------------服務(wù)端偽造證書 攔截請(qǐng)求客戶端如何驗(yàn)證接收到的證書
為了回答這個(gè)問題，需要引入數(shù)字簽名(Digital Signature)。
+---------------------+ | A digital signature | |(not to be confused | |with a digital | |certificate) | +---------+ +--------+ | is a mathematical |----哈希--->| 消息摘要 |---私鑰加密--->| 數(shù)字簽名 | |technique used | +---------+ +--------+ |to validate the | |authenticity and | |integrity of a | |message, software | |or digital document. | +---------------------+將一段文本通過哈希（hash）和私鑰加密處理后生成數(shù)字簽名。
假設(shè)消息傳遞在Bob，Susan和Pat三人之間發(fā)生。Susan將消息連同數(shù)字簽名一起發(fā)送給Bob，Bob接收到消息后，可以這樣驗(yàn)證接收到的消息就是Susan發(fā)送的
+---------------------+ | A digital signature | |(not to be confused | |with a digital | |certificate) | +---------+ | is a mathematical |----哈希--->| 消息摘要 | |technique used | +---------+ |to validate the | | |authenticity and | | |integrity of a | | |message, software | 對(duì) |or digital document. | 比 +---------------------+ |||+--------+ +---------+| 數(shù)字簽名 |---公鑰解密--->| 消息摘要 |+--------+ +---------+當(dāng)然，這個(gè)前提是Bob知道Susan的公鑰。更重要的是，和消息本身一樣，公鑰不能在不安全的網(wǎng)絡(luò)中直接發(fā)送給Bob。此時(shí)就引入了證書頒發(fā)機(jī)構(gòu)（Certificate Authority，簡(jiǎn)稱CA），CA數(shù)量并不多，Bob客戶端內(nèi)置了所有受信任CA的證書。CA對(duì)Susan的公鑰（和其他信息）數(shù)字簽名后生成證書。
Susan將證書發(fā)送給Bob后，Bob通過CA證書的公鑰驗(yàn)證證書簽名。
Bob信任CA，CA信任Susan 使得 Bob信任Susan，信任鏈（Chain Of Trust）就是這樣形成的。
事實(shí)上，Bob客戶端內(nèi)置的是CA的根證書(Root Certificate)，HTTPS協(xié)議中服務(wù)器會(huì)發(fā)送證書鏈（Certificate Chain）給客戶端。
HTTPS的工作原理
HTTPS的優(yōu)點(diǎn)
盡管HTTPS并非絕對(duì)安全，掌握根證書的機(jī)構(gòu)、掌握加密算法的組織同樣可以進(jìn)行中間人形式的攻擊，但HTTPS仍是現(xiàn)行架構(gòu)下最安全的解決方案，主要有以下幾個(gè)好處：
HTTPS的缺點(diǎn)
雖然說HTTPS有很大的優(yōu)勢(shì)，但其相對(duì)來說，還是存在不足之處的：
HTTP 切換到 HTTPS
如果需要將網(wǎng)站從http切換到https到底該如何實(shí)現(xiàn)呢？
這里需要將頁面中所有的鏈接，例如js，css，圖片等等鏈接都由http改為https。例如：http://www.baidu.com改為https://www.baidu.com
BTW，這里雖然將http切換為了https，還是建議保留http。所以我們?cè)谇袚Q的時(shí)候可以做http和https的兼容，具體實(shí)現(xiàn)方式是，去掉頁面鏈接中的http頭部，這樣可以自動(dòng)匹配http頭和https頭。例如：將http://www.baidu.com改為//www.baidu.com。然后當(dāng)用戶從http的入口進(jìn)入訪問頁面時(shí)，頁面就是http，如果用戶是從https的入口進(jìn)入訪問頁面，頁面即使https的。
什么是Cookie，Cookie的使用過程是怎么樣的？
由于 http 協(xié)議是無狀態(tài)協(xié)議，如果客戶通過瀏覽器訪問 web 應(yīng)用時(shí)沒有一個(gè)保存用戶訪問狀態(tài)的機(jī)制，那么將不能持續(xù)跟蹤應(yīng)用的操作。比如當(dāng)用戶往購物車中添加了商品，web 應(yīng)用必須在用戶瀏覽別的商品的時(shí)候仍保存購物車的狀態(tài)，以便用戶繼續(xù)往購物車中添加商品。
cookie 是瀏覽器的一種緩存機(jī)制，它可用于維持客戶端與服務(wù)器端之間的會(huì)話。由于下面一題會(huì)講到session，所以這里要強(qiáng)調(diào)cookie會(huì)將會(huì)話保存在客戶端（session則是把會(huì)話保存在服務(wù)端）
這里以最常見的登陸案例講解cookie的使用過程：
什么是session，有哪些實(shí)現(xiàn)session的機(jī)制？
session 是一種維持客戶端與服務(wù)器端會(huì)話的機(jī)制。但是與 cookie 把會(huì)話信息保存在客戶端本地不一樣，session 把會(huì)話保留在瀏覽器端。
我們同樣以登陸案例為例子講解 session 的使用過程：
看到這里可能會(huì)引起疑問：把唯一的 session 標(biāo)識(shí)返回給客戶端瀏覽器，然后保存起來，以后訪問時(shí)帶上，這難道不是 cookie 嗎？
沒錯(cuò)，session 只是一種會(huì)話機(jī)制，在許多 web 應(yīng)用中，session 機(jī)制就是通過 cookie 來實(shí)現(xiàn)的。也就是說它只是使用了 cookie 的功能，并不是使用 cookie 完成會(huì)話保存。與 cookie 在保存客戶端保存會(huì)話的機(jī)制相反，session 通過 cookie 的功能把會(huì)話信息保存到了服務(wù)端。
進(jìn)一步地說，session 是一種維持服務(wù)端與客戶端之間會(huì)話的機(jī)制，它可以有不同的實(shí)現(xiàn)。以現(xiàn)在比較流行的小程序?yàn)槔?#xff0c;闡述一個(gè) session 的實(shí)現(xiàn)方案：
session和cookie有什么區(qū)別
經(jīng)過上面兩道題的闡述，這道題就很清晰了
Other FAQ
從輸入網(wǎng)址到獲得頁面的過程
XSS 攻擊
XSS 是一種經(jīng)常出現(xiàn)在web應(yīng)用中的計(jì)算機(jī)安全漏洞，與SQL注入一起成為web中最主流的攻擊方式。XSS是指惡意攻擊者利用網(wǎng)站沒有對(duì)用戶提交數(shù)據(jù)進(jìn)行轉(zhuǎn)義處理或者過濾不足的缺點(diǎn)，進(jìn)而添加一些腳本代碼嵌入到web頁面中去，使別的用戶訪問都會(huì)執(zhí)行相應(yīng)的嵌入代碼，從而盜取用戶資料、利用用戶身份進(jìn)行某種動(dòng)作或者對(duì)訪問者進(jìn)行病毒侵害的一種攻擊方式。
IP地址的分類
IP地址是指互聯(lián)網(wǎng)協(xié)議地址，是IP協(xié)議提供的一種統(tǒng)一的地址格式，它為互聯(lián)網(wǎng)上的每一個(gè)網(wǎng)絡(luò)和每一臺(tái)主機(jī)分配一個(gè)邏輯地址，以此來屏蔽物理地址的差異。IP地址編址方案將IP地址空間劃分為A、B、C、D、E五類，其中A、B、C是基本類，D、E類作為多播和保留使用，為特殊地址。
每個(gè)IP地址包括兩個(gè)標(biāo)識(shí)碼（ID），即網(wǎng)絡(luò)ID和主機(jī)ID。同一個(gè)物理網(wǎng)絡(luò)上的所有主機(jī)都使用同一個(gè)網(wǎng)絡(luò)ID，網(wǎng)絡(luò)上的一個(gè)主機(jī)（包括網(wǎng)絡(luò)上工作站，服務(wù)器和路由器等）有一個(gè)主機(jī)ID與其對(duì)應(yīng)。A~E類地址的特點(diǎn)如下：
A類地址：以0開頭，第一個(gè)字節(jié)范圍：0~127；
B類地址：以10開頭，第一個(gè)字節(jié)范圍：128~191；
C類地址：以110開頭，第一個(gè)字節(jié)范圍：192~223；
D類地址：以1110開頭，第一個(gè)字節(jié)范圍為224~239；
E類地址：以1111開頭，保留地址
. 瀏覽器解析并渲染視圖，若遇到對(duì)js文件、css文件及圖片等靜態(tài)資源的引用，則重復(fù)上述步驟并向服務(wù)器請(qǐng)求這些資源；
6. 瀏覽器根據(jù)其請(qǐng)求到的資源、數(shù)據(jù)渲染頁面，最終向用戶呈現(xiàn)一個(gè)完整的頁面。
XSS 攻擊
XSS 是一種經(jīng)常出現(xiàn)在web應(yīng)用中的計(jì)算機(jī)安全漏洞，與SQL注入一起成為web中最主流的攻擊方式。XSS是指惡意攻擊者利用網(wǎng)站沒有對(duì)用戶提交數(shù)據(jù)進(jìn)行轉(zhuǎn)義處理或者過濾不足的缺點(diǎn)，進(jìn)而添加一些腳本代碼嵌入到web頁面中去，使別的用戶訪問都會(huì)執(zhí)行相應(yīng)的嵌入代碼，從而盜取用戶資料、利用用戶身份進(jìn)行某種動(dòng)作或者對(duì)訪問者進(jìn)行病毒侵害的一種攻擊方式。
IP地址的分類
IP地址是指互聯(lián)網(wǎng)協(xié)議地址，是IP協(xié)議提供的一種統(tǒng)一的地址格式，它為互聯(lián)網(wǎng)上的每一個(gè)網(wǎng)絡(luò)和每一臺(tái)主機(jī)分配一個(gè)邏輯地址，以此來屏蔽物理地址的差異。IP地址編址方案將IP地址空間劃分為A、B、C、D、E五類，其中A、B、C是基本類，D、E類作為多播和保留使用，為特殊地址。
每個(gè)IP地址包括兩個(gè)標(biāo)識(shí)碼（ID），即網(wǎng)絡(luò)ID和主機(jī)ID。同一個(gè)物理網(wǎng)絡(luò)上的所有主機(jī)都使用同一個(gè)網(wǎng)絡(luò)ID，網(wǎng)絡(luò)上的一個(gè)主機(jī)（包括網(wǎng)絡(luò)上工作站，服務(wù)器和路由器等）有一個(gè)主機(jī)ID與其對(duì)應(yīng)。A~E類地址的特點(diǎn)如下：
A類地址：以0開頭，第一個(gè)字節(jié)范圍：0~127；
B類地址：以10開頭，第一個(gè)字節(jié)范圍：128~191；
C類地址：以110開頭，第一個(gè)字節(jié)范圍：192~223；
D類地址：以1110開頭，第一個(gè)字節(jié)范圍為224~239；
E類地址：以1111開頭，保留地址
[外鏈圖片轉(zhuǎn)存中…(img-wAepEGXL-1593227236350)]
總結(jié)
以上是生活随笔為你收集整理的计算机网络基础必备（三次握手，四次握手，以及HTTP协议相关）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 数据库相关（JDBC,存储过程，以及大文
- 下一篇： Docker的简单介绍与安装（Windo