柚子快報激活碼778899分享：http 網(wǎng)絡(luò)協(xié)議學(xué)習(xí)筆記

http://yzkb.51969.com/

文章目錄

一、網(wǎng)絡(luò)協(xié)議相關(guān)概念1、三次握手為什么建立連接要3次握手才行，兩次不可以2、四次揮手3、為什么連接的時候是三次握手，關(guān)閉的時候卻是四次握手？4、為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)？5、為什么不能用兩次握手進(jìn)行連接？6、如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？7、TCP/IP工作流程7、TCP和UDP的區(qū)別8、OSI七層網(wǎng)絡(luò)協(xié)議是怎么分層的，每層的作用是什么，舉例說明9、TCP/IP網(wǎng)絡(luò)模型分為哪幾層10、描述一下一個數(shù)據(jù)包在網(wǎng)絡(luò)中的傳輸過程11、什么是socket12、TCP 協(xié)議如何來保證傳輸?shù)目煽啃?3、http和https的區(qū)別14、什么是cookie15、什么是session16、cookie和session的區(qū)別17、怎么通過cookie和session結(jié)合使用實(shí)現(xiàn)登錄緩存？如果是分布式架構(gòu)呢？

二、http1、什么是http協(xié)議2、http協(xié)議是否只能在TCP協(xié)議上使用？3、http工作原理4、http請求特點(diǎn)5、http請求方法6、get和post方法的區(qū)別7、post相較get的優(yōu)缺點(diǎn)8、http狀態(tài)碼9、URL10、http請求構(gòu)成11、http響應(yīng)構(gòu)成12、一次完整的http請求都發(fā)生了什么

三、https1、什么是https2、https工作原理3、https的優(yōu)缺點(diǎn)4、https如何保證安全性5、https安全驗(yàn)證過程

四、dubbo1、什么是dubbo2、為什么要用dubbo3、dubbo的使用場景4、dubbo的核心組件有哪些5、dubbo服務(wù)的注冊發(fā)現(xiàn)流程6、Dubbo 的注冊中心集群掛掉，發(fā)布者和訂閱者之間還能通信么？7、服務(wù)調(diào)用超時會怎么樣？

五、參考資料

一、網(wǎng)絡(luò)協(xié)議相關(guān)概念

1、三次握手

三次揮手四次握手詳細(xì)解析

第一次握手：Client將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個值seq=J，并將該數(shù)據(jù)包發(fā)送給Server，Client進(jìn)入SYN_SENT狀態(tài)，等待Server確認(rèn)。 第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請求建立連接，Server將標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機(jī)產(chǎn)生一個值seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請求，Server進(jìn)入SYN_RCVD狀態(tài)。 第三次握手：Client收到確認(rèn)后，檢查ack是否為J+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了。

為什么建立連接要3次握手才行，兩次不可以

第一次握手：客戶端發(fā)送網(wǎng)絡(luò)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的。

第二次握手：服務(wù)端發(fā)包，客戶端收到了。這樣客戶端就能得出結(jié)論：服務(wù)端的接收、發(fā)送能力，客戶端的接收、發(fā)送能力是正常的。不過此時服務(wù)器并不能確認(rèn)客戶端的接收能力是否正常。

第三次握手：客戶端發(fā)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶端的接收、發(fā)送能力正常，服務(wù)器自己的發(fā)送、接收能力也正常

2、四次揮手

1）客戶端進(jìn)程發(fā)出連接釋放報文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報文首部，F(xiàn)IN=1，其序列號為seq=u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1），此時，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)。 TCP規(guī)定，F(xiàn)IN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。 2）服務(wù)器收到連接釋放報文，發(fā)出確認(rèn)報文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v，此時，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器通知高層的應(yīng)用進(jìn)程，客戶端向服務(wù)器的方向就釋放了，這時候處于半關(guān)閉狀態(tài)，即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。 3）客戶端收到服務(wù)器的確認(rèn)請求后，此時，客戶端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。 4）服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報文，F(xiàn)IN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時的序列號為seq=w，此時，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)。 5）客戶端收到服務(wù)器的連接釋放報文后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進(jìn)入了TIME-WAIT（時間等待）狀態(tài)。注意此時TCP連接還沒有釋放，必須經(jīng)過2??MSL（最長報文段壽命）的時間后，當(dāng)客戶端撤銷相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。 6）服務(wù)器只要收到了客戶端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。同樣，撤銷TCB后，就結(jié)束了這次的TCP連接?？梢钥吹?，服務(wù)器結(jié)束TCP連接的時間要比客戶端早一些。

3、為什么連接的時候是三次握手，關(guān)閉的時候卻是四次握手？

因?yàn)楫?dāng)Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應(yīng)答的，SYN報文是用來同步的。但是關(guān)閉連接時，當(dāng)Server端收到FIN報文時，很可能并不會立即關(guān)閉SOCKET，所以只能先回復(fù)一個ACK報文，告訴Client端，“你發(fā)的FIN報文我收到了”。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。

4、為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)？

雖然按道理，四個報文都發(fā)送完畢，我們可以直接進(jìn)入CLOSE狀態(tài)了，但是我們必須假象網(wǎng)絡(luò)是不可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文。在Client發(fā)送出最后的ACK回復(fù)，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復(fù)發(fā)送FIN片段。所以Client不能立即關(guān)閉，它必須確認(rèn)Server接收到了該ACK。Client會在發(fā)送出ACK之后進(jìn)入到TIME_WAIT狀態(tài)。Client會設(shè)置一個計時器，等待2MSL的時間。如果在該時間內(nèi)再次收到FIN，那么Client會重發(fā)ACK并再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網(wǎng)絡(luò)中最大的存活時間，2MSL就是一個發(fā)送和一個回復(fù)所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接。

5、為什么不能用兩次握手進(jìn)行連接？

3次握手完成兩個重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準(zhǔn)備工作(雙方都知道彼此已準(zhǔn)備好)，也要允許雙方就初始序列號進(jìn)行協(xié)商，這個序列號在握手過程中被發(fā)送和確認(rèn)。 現(xiàn)在把三次握手改成僅需要兩次握手，死鎖是可能發(fā)生的。作為例子，考慮計算機(jī)S和C之間的通信，假定C給S發(fā)送一個連接請求分組，S收到了這個分組，并發(fā) 送了確認(rèn)應(yīng)答分組。按照兩次握手的協(xié)定，S認(rèn)為連接已經(jīng)成功地建立了，可以開始發(fā)送數(shù)據(jù)分組?？墒牵珻在S的應(yīng)答分組在傳輸中被丟失的情況下，將不知道S 是否已準(zhǔn)備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認(rèn)為連接還未建立成功，將忽略S發(fā)來的任何數(shù)據(jù)分 組，只等待連接確認(rèn)應(yīng)答分組。而S在發(fā)出的分組超時后，重復(fù)發(fā)送同樣的分組。這樣就形成了死鎖。 個人理解：好比兩個人找對象，男的問女的，你愿意做我女朋友嗎，女的說我愿意，你呢，男的說我也愿意。如果只有兩次的話，男生最后沒回答，你就不知道他是真想和你處對象還是開玩笑的。

6、如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？

TCP還設(shè)有一個?；钣嫊r器，顯然，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費(fèi)資源。服務(wù)器每收到一次客戶端的請求后都會重新復(fù)位這個計時器，時間通常是設(shè)置為2小時，若兩小時還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會發(fā)送一個探測報文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接。

7、TCP/IP工作流程

在源主機(jī)上，應(yīng)用層將一串應(yīng)用數(shù)據(jù)流傳送給傳輸層。 傳輸層將應(yīng)用層的數(shù)據(jù)流截成分組，并加上TCP報頭形成TCP段，送交網(wǎng)絡(luò)層。 在網(wǎng)絡(luò)層給TCP段加上包括源、目的主機(jī)IP地址的IP報頭，生成一個IP數(shù)據(jù)包，并將IP數(shù)據(jù)包送交鏈路層。 鏈路層在其MAC幀的數(shù)據(jù)部分裝上IP數(shù)據(jù)包，再加上源、目的主機(jī)的MAC地址和幀頭，并根據(jù)其目的MAC地址，將MAC幀發(fā)往目的主機(jī)或IP路由器。 在目的主機(jī)，鏈路層將MAC幀的幀頭去掉，并將IP數(shù)據(jù)包送交網(wǎng)絡(luò)層。 網(wǎng)絡(luò)層檢查IP報頭，如果報頭中校驗(yàn)和與計算結(jié)果不一致，則丟棄該IP數(shù)據(jù)包；若校驗(yàn)和與計算結(jié)果一致，則去掉IP報頭，將TCP段送交傳輸層。 傳輸層檢查順序號，判斷是否是正確的TCP分組，然后檢查TCP報頭數(shù)據(jù)。若正確，則向源主機(jī)發(fā)確認(rèn)信息；若不正確或丟包，則向源主機(jī)要求重發(fā)信息。 在目的主機(jī)，傳輸層去掉TCP報頭，將排好順序的分組組成應(yīng)用數(shù)據(jù)流送給應(yīng)用程序。這樣目的主機(jī)接收到的來自源主機(jī)的字節(jié)流，就像是直接接收來自源主機(jī)的字節(jié)流一樣。

7、TCP和UDP的區(qū)別

TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)協(xié)議屬于傳輸層協(xié)議，它們之間的區(qū)別包括： TCP是面向連接的，UDP是無連接的； TCP是可靠的，UDP是不可靠的； TCP只支持點(diǎn)對點(diǎn)通信，UDP支持一對一、一對多、多對一、多對多的通信模式； TCP是面向字節(jié)流的，UDP是面向報文的； TCP有擁塞控制機(jī)制;UDP沒有擁塞控制，適合媒體通信； TCP首部開銷(20個字節(jié))比UDP的首部開銷(8個字節(jié))要大

8、OSI七層網(wǎng)絡(luò)協(xié)議是怎么分層的，每層的作用是什么，舉例說明

1. 應(yīng)用層：與其它計算機(jī)進(jìn)行通訊的一個應(yīng)用，它是對應(yīng)應(yīng)用程序的通信服務(wù)的示例：telnet，HTTP,FTP,NFS,SMTP等

2. 表示層：這一層的主要功能是定義數(shù)據(jù)格式及加密。示例：加密，ASCII等。

3. 會話層：　它定義了如何開始、控制和結(jié)束一個會話，包括對多個雙向消息的控制和管理，以便在只完成連續(xù)消息的一部分時可以通知應(yīng)用，從而使表示層看到的數(shù)據(jù)是連續(xù)的，在某些情況下，如果表示層收到了所有的數(shù)據(jù)，則用數(shù)據(jù)代表表示層示例：RPC，SQL等。

4. 傳輸層：這層的功能包括是否選擇差錯恢復(fù)協(xié)議還是無差錯恢復(fù)協(xié)議，及在同一主機(jī)上對不同應(yīng)用的數(shù)據(jù)流的輸入進(jìn)行復(fù)用，還包括對收到的順序不對的數(shù)據(jù)包的重新排序功能示例：TCP，UDP，SPX。

5. 網(wǎng)絡(luò)層：這層對端到端的包傳輸進(jìn)行定義，它定義了能夠標(biāo)識所有結(jié)點(diǎn)的邏輯地址，還定義了路由實(shí)現(xiàn)的方式和學(xué)習(xí)的方式。為了適應(yīng)最大傳輸單元長度小于包長度的傳輸介質(zhì)，網(wǎng)絡(luò)層還定義了如何將一個包分解成更小的包的分段方法示例：IP,IPX等

6. 數(shù)據(jù)鏈路層：　它定義了在單個鏈路上如何傳輸數(shù)據(jù)。這些協(xié)議與被討論的各種介質(zhì)有關(guān)。示例：ATM，F(xiàn)DDI等

7. 物理層：OSI的物理層規(guī)范是有關(guān)傳輸介質(zhì)的特性標(biāo)準(zhǔn)，這些規(guī)范通常也參考了其他組織制定的標(biāo)準(zhǔn)示例：Rj45，802.3等

9、TCP/IP網(wǎng)絡(luò)模型分為哪幾層

應(yīng)用層 TELNET、HTTP、FTP、DNS傳輸層 TCP、UDP 它提供了節(jié)點(diǎn)間的數(shù)據(jù)傳送，應(yīng)用程序之間的通信服務(wù)，主要功能是數(shù)據(jù)格式化、數(shù)據(jù)確認(rèn)和丟失重傳等。網(wǎng)絡(luò)層 IP、ARP 負(fù)責(zé)提供基本的數(shù)據(jù)封包傳送功能，讓每一塊數(shù)據(jù)包都能夠到達(dá)目的主機(jī)數(shù)據(jù)鏈路層（TCP/IP五層模型和四層模型的區(qū)別）網(wǎng)絡(luò)接口層 接收IP數(shù)據(jù)報并進(jìn)行傳輸，從網(wǎng)絡(luò)上接收物理幀，抽取IP數(shù)據(jù)報轉(zhuǎn)交給下一層

10、描述一下一個數(shù)據(jù)包在網(wǎng)絡(luò)中的傳輸過程

在應(yīng)用層，由http頭等應(yīng)用層傳輸協(xié)議組成的報文頭和數(shù)據(jù)包，組成一個新數(shù)據(jù)包傳到傳輸層傳輸層將數(shù)據(jù)包和TCP報頭生成新的tcp報文，傳到網(wǎng)絡(luò)層網(wǎng)絡(luò)層加上IP報頭組成新的ip報文，傳到物理層物理層開始傳輸，在局域網(wǎng)和廣域網(wǎng)通過ip尋址，不斷解析和封裝鏈路層和網(wǎng)絡(luò)層，知道找到目標(biāo)主機(jī)找到目標(biāo)主機(jī)后，開始逐層解析數(shù)據(jù)包，網(wǎng)絡(luò)層解析ip數(shù)據(jù)包，傳輸層解析tcp數(shù)據(jù)包，應(yīng)用層解析http數(shù)據(jù)包網(wǎng)絡(luò)數(shù)據(jù)傳輸就是通過一個個數(shù)據(jù)包的傳輸組成，通過一系列網(wǎng)絡(luò)協(xié)議來保證尋址準(zhǔn)備，以及數(shù)據(jù)的完整性、安全性等

11、什么是socket

socket是一組接口，在應(yīng)用層和傳輸層之間的一個抽象層，它把TCP/IP層復(fù)雜的操作抽象為幾個簡單的接口供應(yīng)用層調(diào)用已實(shí)現(xiàn)進(jìn)程在網(wǎng)絡(luò)中通信

12、TCP 協(xié)議如何來保證傳輸?shù)目煽啃?/p>

TCP 提供一種面向連接的、可靠的字節(jié)流服務(wù)。其中，面向連接意味著兩個使用 TCP 的應(yīng)用（通常是一個客戶和一個服務(wù)器）在彼此交換數(shù)據(jù)之前必須先建立一個 TCP 連接。在一個 TCP 連接中，僅有兩方進(jìn)行彼此通信；而字節(jié)流服務(wù)意味著兩個應(yīng)用程序通過 TCP 鏈接交換 8 bit 字節(jié)構(gòu)成的字節(jié)流，TCP 不在字節(jié)流中插入記錄標(biāo)識符。 對于可靠性，TCP通過以下方式進(jìn)行保證： 數(shù)據(jù)包校驗(yàn)：目的是檢測數(shù)據(jù)在傳輸過程中的任何變化，若校驗(yàn)出包有錯，則丟棄報文段并且不給出響應(yīng)，這時TCP發(fā)送數(shù)據(jù)端超時后會重發(fā)數(shù)據(jù)； 對失序數(shù)據(jù)包重排序：既然TCP報文段作為IP數(shù)據(jù)報來傳輸，而IP數(shù)據(jù)報的到達(dá)可能會失序，因此TCP報文段的到達(dá)也可能會失序。TCP將對失序數(shù)據(jù)進(jìn)行重新排序，然后才交給應(yīng)用層； 丟棄重復(fù)數(shù)據(jù)：對于重復(fù)數(shù)據(jù)，能夠丟棄重復(fù)數(shù)據(jù)； 應(yīng)答機(jī)制：當(dāng)TCP收到發(fā)自TCP連接另一端的數(shù)據(jù)，它將發(fā)送一個確認(rèn)。這個確認(rèn)不是立即發(fā)送，通常將推遲幾分之一秒； 超時重發(fā)：當(dāng)TCP發(fā)出一個段后，它啟動一個定時器，等待目的端確認(rèn)收到這個報文段。如果不能及時收到一個確認(rèn)，將重發(fā)這個報文段； 流量控制：TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出，這就是流量控制。TCP使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。

13、http和https的區(qū)別

1、https協(xié)議需要到CA申請證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。 2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl/tls加密傳輸協(xié)議。 3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。 4、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL/TLS+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

14、什么是cookie

在網(wǎng)站中，http請求是無狀態(tài)的。也就是說即使第一次和服務(wù)器連接后并且登錄成功后，第二次請求服務(wù)器依然不能知道當(dāng)前請求是哪個用戶。cookie的出現(xiàn)就是為了解決這個問題，第一次登錄后服務(wù)器返回一些數(shù)據(jù)（cookie）給瀏覽器，然后瀏覽器保存在本地，當(dāng)該用戶發(fā)送第二次請求的時候，就會自動的把上次請求存儲的cookie數(shù)據(jù)自動的攜帶給服務(wù)器，服務(wù)器通過瀏覽器攜帶的數(shù)據(jù)就能判斷當(dāng)前用戶是哪個了。cookie存儲的數(shù)據(jù)量有限，不同的瀏覽器有不同的存儲大小，但一般不超過4KB。因此使用cookie只能存儲一些小量的數(shù)據(jù)。

15、什么是session

session和cookie的作用有點(diǎn)類似，都是為了存儲用戶相關(guān)的信息。不同的是，cookie是存儲在本地瀏覽器，而session存儲在服務(wù)器。存儲在服務(wù)器的數(shù)據(jù)會更加的安全，不容易被竊取。但存儲在服務(wù)器也有一定的弊端，就是會占用服務(wù)器的資源，但現(xiàn)在服務(wù)器已經(jīng)發(fā)展至今，一些session信息還是綽綽有余的。

16、cookie和session的區(qū)別

1、cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上. 2、cookie不是很安全，別人可以分析存放在本地的COOKIE并進(jìn)行COOKIE欺騙考慮到安全應(yīng)當(dāng)使用session。 3、設(shè)置cookie時間可以使cookie過期。但是使用session-destory（），我們將會銷毀會話。 4、session會在一定時間內(nèi)保存在服務(wù)器上。當(dāng)訪問增多，會比較占用你服務(wù)器的性能考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用cookie。 5、單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點(diǎn)最多保存20個cookie。(Session對象沒有對存儲的數(shù)據(jù)量的限制，其中可以保存更為復(fù)雜的數(shù)據(jù)類型) 6、 兩者最大的區(qū)別在于生存周期，一個是IE啟動到IE關(guān)閉.(瀏覽器頁面一關(guān) ,session就消失了)，一個是預(yù)先設(shè)置的生存周期，或永久的保存于本地的文件。(cookie)

17、怎么通過cookie和session結(jié)合使用實(shí)現(xiàn)登錄緩存？如果是分布式架構(gòu)呢？

二、http

1、什么是http協(xié)議

超文本傳輸協(xié)議，是一個基于請求與響應(yīng)，無狀態(tài)的，應(yīng)用層的協(xié)議，?；赥CP/IP協(xié)議傳輸數(shù)據(jù)，互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個標(biāo)準(zhǔn)。設(shè)計HTTP的初衷是為了提供一種發(fā)布和接收HTML頁面的方法。

2、http協(xié)議是否只能在TCP協(xié)議上使用？

1、http可以在任何互聯(lián)網(wǎng)協(xié)議上、或其他網(wǎng)絡(luò)上實(shí)現(xiàn)。http假定其下層協(xié)議提供可靠的傳輸，任何能夠提供這種保證的協(xié)議都可以被其使用，TCP/IP協(xié)議只是其中的一種 2、http協(xié)議是基于TCP/IP協(xié)議之上的應(yīng)用層協(xié)議

3、http工作原理

1、向DNS服務(wù)器解析URL，然后通過url和端口和服務(wù)器建立連接 2、發(fā)送http請求，客戶端向服務(wù)端發(fā)送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數(shù)據(jù)組成 3、服務(wù)器接收請求并返回http響應(yīng)，一個響應(yīng)由狀態(tài)行，響應(yīng)頭部、空行和響應(yīng)數(shù)據(jù)組成 4、如果是短連接，則服務(wù)器自動斷開連接，如果是長連接，可以繼續(xù)接收請求 5、客戶端解析響應(yīng)內(nèi)容并展示

4、http請求特點(diǎn)

1、基于請求-響應(yīng)模式。請求必定從服務(wù)端發(fā)出，然后服務(wù)器再做出響應(yīng) 2、無狀態(tài)保存。不保存處理過的狀態(tài)，每次請求都產(chǎn)生對應(yīng)的新響應(yīng)，目的是為了處理大量事務(wù)，確保協(xié)議的可伸縮性。如果為了特定場景下可以保存狀態(tài)，可以使用cookie技術(shù)，比如登錄狀態(tài)需要長時間保持 3、無連接。每次只處理一個請求，處理完畢后斷開連接。有兩種方式，直接斷開和等一段時間后斷開，默認(rèn)3秒，可以通過代碼調(diào)整

5、http請求方法

1、GET、HEAD、POST、PUT、DELETE、TRACE、OPTIONS、CONNECT 2、方法名是區(qū)分大小寫的。當(dāng)服務(wù)器不認(rèn)識請求方法，放回501；服務(wù)器不支持對應(yīng)的請求方法，返回405

6、get和post方法的區(qū)別

1、數(shù)據(jù)提交方式不同。get放在URL后，用？分隔。post放在請求體中 2、get有長度限制，post沒有。get長度受限于url長度，最長2048 3、get請求可以被緩存，post不可以 4、get只能用ASCII編碼，post沒有字符類型限制

7、post相較get的優(yōu)缺點(diǎn)

1、post相對更安全。post用請求體傳輸數(shù)據(jù)，不會被緩存，沒有歷史記錄。 2、post沒有字符和編碼的限制，可以傳輸?shù)臄?shù)據(jù)類型更多 3、post沒有數(shù)據(jù)大小限制，可以傳輸更多數(shù)據(jù) 4、缺點(diǎn)：post傳輸速度比get慢，get效率更高。原因：post接收數(shù)據(jù)會先確認(rèn)，再傳輸，get則直接發(fā)送數(shù)據(jù)。

8、http狀態(tài)碼

T類別原因短語1XXInformational(信息性狀態(tài)碼)接收的請求正在處理2XXSuccess(成功狀態(tài)碼)請求正常處理完畢3XXRedirectiono(重定向狀態(tài)碼)需要進(jìn)行附加操作已完成請求4XXClient Error(客戶端錯誤狀態(tài)碼)服務(wù)器無法處理請求5XXSever Error(服務(wù)器錯誤狀態(tài)碼)服務(wù)器處理請求出錯

9、URL

1、傳輸協(xié)議 2、層級URL標(biāo)記符號，為//，固定不變 3、訪問資源需要的憑證信息 4、服務(wù)器。域名或ip 5、端口號 6、路徑。以/分隔路徑的每一個目錄名稱） 7、查詢。以？為起點(diǎn) 8、片段。以#為起點(diǎn)

10、http請求構(gòu)成

請求行 請求方法字段、URL字段和HTTP協(xié)議版本請求頭 key：value格式，空行 通知服務(wù)器以下不再有請求頭請求體 請求數(shù)據(jù)

11、http響應(yīng)構(gòu)成

響應(yīng)行 協(xié)議版本、狀態(tài)碼及其描述 HTTP/1.1 200 OK響應(yīng)頭空行響應(yīng)體

12、一次完整的http請求都發(fā)生了什么

1.在瀏覽器端輸入網(wǎng)站的url地址 2.瀏覽器查找緩存（如果有的話，直接返回顯示，如果沒有的話，繼續(xù)下一步） 3.通過DNS獲取url對應(yīng)的IP地址（先在本機(jī)的host文件中查找是否有這個url對應(yīng)的IP，如果沒有的話，就請求DNS進(jìn)行IP地址的獲?。?4.建立TCP連接（http在工作之前，需要客戶端和服務(wù)端建立連接，這個鏈接的建立時通過TCP三次握手來完成的） 5.瀏覽器向web服務(wù)器發(fā)送請求（一旦連接已經(jīng)建立，瀏覽器就可以給web服務(wù)器發(fā)送請求命令，比如GET/deom/hello.jsp HTTP/1.1） 6.瀏覽器給web服務(wù)器發(fā)送請求頭信息（瀏覽器在發(fā)送了請求后，還要給web服務(wù)器請求頭信息） 7.web服務(wù)器進(jìn)行應(yīng)答（http/1.1 200 OK) 8.web服務(wù)器發(fā)送應(yīng)答頭消息 9.web服務(wù)器發(fā)送數(shù)據(jù) 10.web服務(wù)器關(guān)閉連接（TCP四次揮手）

三、https

http加密原理

1、什么是https

是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。

2、https工作原理

1、client向server發(fā)送請求https://baidu.com，然后連接到server的443端口，發(fā)送的信息主要是隨機(jī)值1和客戶端支持的加密算法。 2、server接收到信息之后給予client響應(yīng)握手信息，包括隨機(jī)值2和匹配好的協(xié)商加密算法，這個加密算法一定是client發(fā)送給server加密算法的子集。 3、隨即server給client發(fā)送第二個響應(yīng)報文是數(shù)字證書。服務(wù)端必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請。區(qū)別就是自己頒發(fā)的證書需要客戶端驗(yàn)證通過，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面，這套證書其實(shí)就是一對公鑰和私鑰。傳送證書，這個證書其實(shí)就是公鑰，只是包含了很多信息，如證書的頒發(fā)機(jī)構(gòu)，過期時間、服務(wù)端的公鑰，第三方證書認(rèn)證機(jī)構(gòu)(CA)的簽名，服務(wù)端的域名信息等內(nèi)容。 4、客戶端解析證書，這部分工作是由客戶端的TLS來完成的，首先會驗(yàn)證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨即值（預(yù)主秘鑰）。 5、客戶端認(rèn)證證書通過之后，接下來是通過隨機(jī)值1、隨機(jī)值2和預(yù)主秘鑰組裝會話秘鑰。然后通過證書的公鑰加密會話秘鑰。 6、傳送加密信息，這部分傳送的是用證書加密后的會話秘鑰，目的就是讓服務(wù)端使用秘鑰解密得到隨機(jī)值1、隨機(jī)值2和預(yù)主秘鑰。 7、服務(wù)端解密得到隨機(jī)值1、隨機(jī)值2和預(yù)主秘鑰，然后組裝會話秘鑰，跟客戶端會話秘鑰相同。 8、客戶端通過會話秘鑰加密一條消息發(fā)送給服務(wù)端，主要驗(yàn)證服務(wù)端是否正常接受客戶端加密的消息。 9、同樣服務(wù)端也會通過會話秘鑰加密一條消息回傳給客戶端，如果客戶端能夠正常接受的話表明SSL層連接建立完成了。

3、https的優(yōu)缺點(diǎn)

缺點(diǎn)：

（1）HTTPS協(xié)議握手階段比較費(fèi)時，會使頁面的加載時間延長近50%，增加10%到20%的耗電；

（2）HTTPS連接緩存不如HTTP高效，會增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會因此而受到影響；

（3）SSL證書需要錢，功能越強(qiáng)大的證書費(fèi)用越高，個人網(wǎng)站、小網(wǎng)站沒有必要一般不會用。

（4）SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。

（5）HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。最關(guān)鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。

優(yōu)點(diǎn)

盡管HTTPS并非絕對安全，掌握根證書的機(jī)構(gòu)、掌握加密算法的組織同樣可以進(jìn)行中間人形式的攻擊，但HTTPS仍是現(xiàn)行架構(gòu)下最安全的解決方案，主要有以下幾個好處：

（1）使用HTTPS協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；

（2）HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。

（3）HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。

（4）谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS加密的網(wǎng)站在搜索結(jié)果中的排名將會更高”。

4、https如何保證安全性

https如何保證安全性 1、證書 2、數(shù)字簽名 3、公私鑰

5、https安全驗(yàn)證過程

https安全性保證過程

1、客戶端向服務(wù)端發(fā)送SSL協(xié)議版本號、加密算法種類、隨機(jī)數(shù)等信息; 2、服務(wù)端給客戶端返回SSL協(xié)議版本號、加密算法種類、隨機(jī)數(shù)等信息，同時也返回服務(wù)器端的證書，即公鑰證書; 3、客戶端使用服務(wù)端返回的信息驗(yàn)證服務(wù)器的合法性，包括： 4、證書是否過期;

發(fā)行服務(wù)器證書的CA是否可靠;(通過查詢?yōu)g覽器或本機(jī)內(nèi)的CA證書)返回的公鑰是否能正確解開返回證書中的數(shù)字簽名;（通過使用本機(jī)或?yàn)g覽器內(nèi)置的CA公鑰進(jìn)行解密）服務(wù)器證書上的域名是否和服務(wù)器的實(shí)際域名相匹配;驗(yàn)證通過后，將繼續(xù)進(jìn)行通信，否則，終止通信;服務(wù)端要求客戶端發(fā)送客戶端的證書即客戶端證書公鑰，客戶端會將自己的證書發(fā)送至服務(wù)端； 5、驗(yàn)證客戶端的證書，通過驗(yàn)證后，會獲得客戶端的公鑰； 6、客戶端向服務(wù)端發(fā)送自己所能支持的對稱加密方案，供服務(wù)器端進(jìn)行選擇 7、服務(wù)器端在客戶端提供的加密方案中選擇加密程度最高的加密方式; 8、將加密方案通過使用之前獲取到的公鑰進(jìn)行加密，返回給客戶端 9、客戶端收到服務(wù)端返回的加密方案密文后，使用自己的私鑰進(jìn)行解密，獲取具體加密方式，而后，產(chǎn)生該加密方式的隨機(jī)碼，用作加密過程中的密鑰，使用之前從服務(wù)端證書中獲取到的公鑰進(jìn)行加密后，發(fā)送給服務(wù)端 ； 10、服務(wù)端收到客戶端發(fā)送的消息后，使用自己的私鑰進(jìn)行解密，獲取對稱加密的密鑰，在接下來的會話中，服務(wù)器和客戶端將會使用該密碼進(jìn)行對稱加密，保證通信過程中信息的安全

四、dubbo

1、什么是dubbo

Dubbo 是alibaba開源的一款高性能、輕量級的開源 RPC 框架，提供服務(wù)自動注冊、自動發(fā)現(xiàn)等高效服務(wù)治理方案

2、為什么要用dubbo

隨著服務(wù)化的進(jìn)一步發(fā)展，服務(wù)越來越多，服務(wù)之間的調(diào)用和依賴關(guān)系也越來越復(fù)雜，誕生了面向服務(wù)的架構(gòu)體系(SOA)，也因此衍生出了一系列相應(yīng)的技術(shù)，如對服務(wù)提供、服務(wù)調(diào)用、連接處理、通信協(xié)議、序列化方式、服務(wù)發(fā)現(xiàn)、服務(wù)路由、日志輸出等行為進(jìn)行封裝的服務(wù)框架。就這樣為分布式系統(tǒng)的服務(wù)治理框架就出現(xiàn)了，Dubbo 也就這樣產(chǎn)生了。

3、dubbo的使用場景

1、服務(wù)自動注冊與發(fā)現(xiàn) 2、軟負(fù)載均衡及容錯機(jī)制 3、透明化的遠(yuǎn)程方法調(diào)用

4、dubbo的核心組件有哪些

Provider：暴露服務(wù)的服務(wù)提供方 Consumer：調(diào)用遠(yuǎn)程服務(wù)消費(fèi)方 Registry：服務(wù)注冊與發(fā)現(xiàn)注冊中心 Monitor：監(jiān)控中心和訪問調(diào)用統(tǒng)計 Container：服務(wù)運(yùn)行容器

5、dubbo服務(wù)的注冊發(fā)現(xiàn)流程

服務(wù)容器Container負(fù)責(zé)啟動，加載，運(yùn)行服務(wù)提供者。 服務(wù)提供者Provider在啟動時，向注冊中心注冊自己提供的服務(wù)。 服務(wù)消費(fèi)者Consumer在啟動時，向注冊中心訂閱自己所需的服務(wù)。 注冊中心Registry返回服務(wù)提供者地址列表給消費(fèi)者，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費(fèi)者。 服務(wù)消費(fèi)者Consumer，從提供者地址列表中，基于軟負(fù)載均衡算法，選一臺提供者進(jìn)行調(diào)用，如果調(diào)用失敗，再選另一臺調(diào)用。 服務(wù)消費(fèi)者Consumer和提供者Provider，在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心Monitor。

6、Dubbo 的注冊中心集群掛掉，發(fā)布者和訂閱者之間還能通信么？

可以通訊。啟動 Dubbo 時，消費(fèi)者會從 Zookeeper 拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù)，緩存在本地。每次調(diào)用時，按照本地存儲的地址進(jìn)行調(diào)用。

7、服務(wù)調(diào)用超時會怎么樣？

dubbo 在調(diào)用服務(wù)不成功時，默認(rèn)是會重試兩次。

五、參考資料

1、網(wǎng)絡(luò)協(xié)議詳解 2、TCP協(xié)議詳細(xì)介紹 3、網(wǎng)絡(luò)數(shù)據(jù)的完整傳輸過程解析 4、一個簡單題庫 5、比較全的網(wǎng)絡(luò)協(xié)議面試題 6、網(wǎng)絡(luò)尋址過程

柚子快報激活碼778899分享：http 網(wǎng)絡(luò)協(xié)議學(xué)習(xí)筆記

http://yzkb.51969.com/

精彩鏈接