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