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