HTTP協(xié)議簡介

1.協(xié)議：指計算機(jī)通信網(wǎng)絡(luò)中兩臺計算機(jī)之間進(jìn)行通信所必須共同遵守的規(guī)則或規(guī)定

2.HTTP協(xié)議：超文本傳輸協(xié)議(HTTP)是一種傳輸協(xié)議缩功，它允許將超文本標(biāo)記語言(HTML)文檔從web服務(wù)器傳送到客戶端的瀏覽器，HTTP協(xié)議處于計算機(jī)網(wǎng)絡(luò)中的應(yīng)用層疟赊。

URI和URL的區(qū)別

URI (uniform resource identifier) : 統(tǒng)一資源標(biāo)識符，用來唯一的標(biāo)識一個資源

URI的組成部分

• 訪問資源的命名機(jī)制
• 存放資源的主機(jī)名
• 資源自身的名稱眠蚂，由路徑標(biāo)識，著重強(qiáng)調(diào)于資源

例如：file://a:1234/b/c/d.txt 使用ftp協(xié)議表示的資源目標(biāo)是在a主機(jī)下的1234端口的b目錄下的c目錄的d.txt文件，file是訪問資源的命名機(jī)制，a:1234是主機(jī)名谒所，b/c/d.txt是路徑

URL (uniform resource locator) : 統(tǒng)一資源定位器固惯，它是一種具體的URI，即URL可以用來標(biāo)識一個資源蝶念，而且還指明了如何locate這個資源

URL的組成部分

• 協(xié)議
• 存有該資源的主機(jī)IP地址
• 主機(jī)資源的具體地址

例如：http://www.baidu.com

HTTP協(xié)議的特點(diǎn)

• 簡單快速
• 無連接
• 無狀態(tài)

Http1.1和Http1.0及2.0的區(qū)別

HTTP1.1與1.0的區(qū)別

• 長連接

  HTTP1.0協(xié)議使用非持久連接抛腕，即在非持久連接下，一個TCP連接只傳輸一個Web對象媒殉。

  HTTP1.1支持持久連接担敌，也就是說長連接，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)廷蓉，減少了建立和關(guān)閉連接的消耗和延遲全封。

  一個包含有許多圖像的網(wǎng)頁文件的多個請求和應(yīng)答可以在一個連接中傳輸，但每個單獨(dú)的網(wǎng)頁文件的請求和應(yīng)答仍然需要使用各自的連接。HTTP1.1還允許客戶端不要等待上一次請求結(jié)果返回刹悴，就可以發(fā)出下一次請求给猾，但服務(wù)器端必須按照接收到客戶端請求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶端能夠區(qū)分出每次請求的響應(yīng)內(nèi)容颂跨，這樣就顯著的減少了整個下載過程所需要的時間。

  HTTP1.0需要使用keep-alive參數(shù)來告知服務(wù)器端要建立一個長連接扯饶，而HTTP1.1默認(rèn)支持長連接恒削。HTTP是基于TCP/IP協(xié)議的，創(chuàng)建一個TCP連接是需要經(jīng)過三次握手的尾序，有一定的開銷钓丰，如果每次通訊都要重新建立連接的話，對性能有影響每币。因此最好能維持一個長連接携丁。

• 緩存處理

  HTTP/1.0使用頭部當(dāng)中的 If-Modified-Since 參數(shù)作為緩存判斷的標(biāo)準(zhǔn)，HTTP1.1引入了更多的緩存控制策略兰怠，比如Etag / if-None-Match

• 帶寬優(yōu)化

  HTTP/1.0中梦鉴，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是請求某個對象的一小部分揭保，而服務(wù)器卻將整個對象傳送過來肥橙。例如，客戶端只需要顯示一個文檔的部分內(nèi)容秸侣，又比如下載大文件需要支持?jǐn)帱c(diǎn)續(xù)傳存筏，而不是發(fā)送斷開連接后不得不重新下載完整的包。

  HTTP1.1中在請求消息中引入了range頭域味榛，他允許我們只請求資源的某個部分椭坚。在響應(yīng)消息中Content-Range頭域聲明了返回的這部分對象的偏移值和長度。如果服務(wù)器響應(yīng)的返回了對象所請求范圍的內(nèi)容搏色，則響應(yīng)碼為206善茎，它可以防止Cache將響應(yīng)誤以為是一個完整的對象。

  節(jié)省帶寬資源的一個非常有效的做法就是壓縮要傳送的數(shù)據(jù)继榆。

• Host頭處理

  HTTP/1.0中巾表，我們認(rèn)為每臺服務(wù)器綁定唯一的IP地址略吨，因此請求消息中的URL并沒有重定向翠忠。但是這兩年鞠苟，隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺物理服務(wù)器上可以存在多個虛擬主機(jī)共享一個IP地址当娱。HTTP1.1在這方面做了改進(jìn)，它的請求消息和響應(yīng)消息都支持Host頭跨细，并且在請求消息中如果沒有Host域鹦倚，就會報告一個400錯誤。

HTTP1.1與HTTP1.0存在的問題

• HTTP1.0在傳輸數(shù)據(jù)時每次都需要建立長連接震叙，無疑增加了大量的延遲時間媒楼。HTTP1.1長連接解決了這個問題
• HTTP1.x在傳輸數(shù)據(jù)時戚丸，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)端都無法驗(yàn)證對方的身份夺颤，在一定程度上無法保證數(shù)據(jù)的安全性拂共∫黾福可以通過HTTPS來保證數(shù)據(jù)安全
• HTTP1.x在使用時蛇捌，header里攜帶的內(nèi)容過大，在一定程度上增加了傳輸?shù)某杀尽?/li>
• 雖然HTTP1.1支持了keep-alive,來彌補(bǔ)多次創(chuàng)建連接產(chǎn)生的延遲俭驮，但是keep-alive使用多了同樣會給服務(wù)端帶來大量的性能壓力

HTTP1.1與HTTP2.0的區(qū)別

• 多路復(fù)用

  HTTP2.0使用了多路復(fù)用的技術(shù)混萝，做到同一個連接并發(fā)處理多個請求萍恕，而且并發(fā)請求的數(shù)量比HTTP1.1大了好幾個數(shù)量級。

  當(dāng)然HTTP1.1也可以多建立幾個TCP連接崭倘，來支持處理更多并發(fā)的請求司光，但是創(chuàng)建TCP連接本身也是有開銷的。

  TCP連接有一個預(yù)熱和保護(hù)的過程榆俺，先檢查數(shù)據(jù)是否傳送成功坞淮，一旦成功過后碾盐，則會慢慢增加傳輸速度毫玖，因此對應(yīng)瞬時并發(fā)的鏈接凌盯，服務(wù)器的響應(yīng)就會變慢驰怎。所以最好能使用一個建立好的連接，并且這個連接支持瞬時并發(fā)的請求掂榔。

• 數(shù)據(jù)壓縮

  我們知道装获，HTTP請求和響應(yīng)都是由狀態(tài)行厉颤、請求/響應(yīng)頭部逼友，消息主體三部分組成的。一般而言司抱，消息主體都會經(jīng)過gzip壓縮挖函，或者本身傳輸?shù)木褪菈嚎s過后的二進(jìn)制文件（如圖片、音頻等）振定，但是狀態(tài)行和頭部多是沒有經(jīng)過任何壓縮肉拓，而是以純文本的方式進(jìn)行傳輸?shù)摹?/p>

  然而暖途，隨著web功能越來越多驻售，請求數(shù)量越來越多，隨之而來的就是頭部的流量越來越多毫痕，并且在建立初次連接之后的鏈接也要發(fā)送User-Agent等信息迟几，實(shí)在是一種浪費(fèi)类腮，因此蚜枢，HTTP2.0提出了對請求和響應(yīng)的頭部進(jìn)行壓縮，而不只是壓縮主體部分察滑，這種壓縮方式就是HAPCK贺辰。

• 服務(wù)器推送

  為了改善延遲嵌施，HTTP2.0引入了Server Push吗伤，它允許服務(wù)端推送資源給瀏覽器，在瀏覽器明確的請求之前巢块，一個服務(wù)器經(jīng)常知道一個頁面需要很多附加資源族奢，在它響應(yīng)瀏覽器第一個請求的時候，就可以開始推送這些資源棚品。這允許服務(wù)端充分的利用一個可能空閑的網(wǎng)絡(luò)铜跑，改善頁面加載時間骡澈。

Http的request和response的協(xié)議組成

請求消息包括請求行（request line）肋殴、請求頭部（header）疼电、空行和請求數(shù)據(jù)四個部分組成

請求行由請求方法减拭、URL字段和HTTP協(xié)議的版本組成拧粪，格式如下：Method Request-URI HTTP-Version CRLF

其中 Method表示請求方法可霎；Request-URI是一個統(tǒng)一資源標(biāo)識符；HTTP-Version表示請求的HTTP協(xié)議版本拾因；CRLF表示回車和換行（除了作為結(jié)尾的CRLF外绢记，不允許出現(xiàn)單獨(dú)的CR或LF字符）正卧。

HTTP請求方法有8種炉旷，分別是GET、POST饥追、HEAD判耕、PUT壁熄、DELETE、TRACE狸臣、CONNECT烛亦、OPTIONS懂拾。對于移動開發(fā)最常用的就是GET和POST了岖赋。

請求數(shù)據(jù)不在GET方法中使用唐断，而在POST方法中使用。POST方法適用于需要客戶填寫表單的場合恳啥，與請求數(shù)據(jù)相關(guān)的最常用的請求報頭是Content-Type和Content-Length钝的。

HTTP 的響應(yīng)報文由狀態(tài)行扁藕、響應(yīng)報頭疚脐、空行棍弄、響應(yīng)正文組成。

狀態(tài)行格式如下所示：HTTP-Version Status-Code Reason-Phrase CRLF

其中颁虐，HTTP-Version表示服務(wù)器HTTP協(xié)議的版本卧须；Status-Code表示服務(wù)器發(fā)回的響應(yīng)狀態(tài)碼花嘶；Reason-
Phrase表示狀態(tài)碼的文本描述椭员。狀態(tài)碼由3位數(shù)字組成隘击，第一個數(shù)字定義了響應(yīng)的類別，且有以下5種可能取值州叠。
? 100～199：指示信息咧栗，收到請求，需要請求者繼續(xù)執(zhí)行操作忆绰。
? 200～299：請求成功错敢，請求已被成功接收并處理稚茅。
? 300～399：重定向，要完成請求必須進(jìn)行更進(jìn)一步的操作咽块。
? 400～499：客戶端錯誤侈沪，請求有語法錯誤或請求無法實(shí)現(xiàn)亭罪。
? 500～599：服務(wù)器錯誤应役，服務(wù)器不能實(shí)現(xiàn)合法的請求。
常見的狀態(tài)碼如下:
? 200 OK：客戶端請求成功院崇。
? 400 Bad Request：客戶端請求有語法錯誤亚脆，服務(wù)器無法理解濒持。
? 401 Unauthorized：請求未經(jīng)授權(quán)柑营，這個狀態(tài)碼必須和WWW-Authenticate報頭域一起使用村视。
? 403 Forbidden：服務(wù)器收到請求蚁孔，但是拒絕提供服務(wù)杠氢。
? 500 Internal Server Error：服務(wù)器內(nèi)部錯誤鼻百，無法完成請求。
? 503 Server Unavailable：服務(wù)器當(dāng)前不能處理客戶端的請求因悲，一段時間后可能恢復(fù)正常晃琳。

消息報頭

消息報頭分為通用報頭蝎土、請求報頭誊涯、響應(yīng)報頭暴构、實(shí)體報頭等。消息報頭由鍵值對組成耗绿，每行一對误阻，關(guān)
鍵字和值用英文冒號“：”分隔究反。

1.通用報頭：它既可以出現(xiàn)在請求報頭精耐，也可以出現(xiàn)在響應(yīng)報頭中琅锻，如下所示
? Date：表示消息產(chǎn)生的日期和時間恼蓬。
? Connection：允許發(fā)送指定連接的選項(xiàng)处硬。例如指定連接是連續(xù)的郁油；或者指定“close”選項(xiàng)桐腌，通知服務(wù)
器苟径，在響應(yīng)完成后棘街，關(guān)閉連接。
? Cache-Control：用于指定緩存指令博助，緩存指令是單向的（響應(yīng)中出現(xiàn)的緩存指令在請求中未必會出
現(xiàn)）富岳，且是獨(dú)立的（一個消息的緩存指令不會影響另一個消息處理的緩存機(jī)制）窖式。

2.請求報頭：通知服務(wù)器關(guān)于客戶端請求的信息萝喘。典型的請求報頭如下所示
? Host：請求的主機(jī)名阁簸，允許多個域名同處一個IP地址强窖，即虛擬主機(jī)削祈。
? User-Agent：發(fā)送請求的瀏覽器類型髓抑、操作系統(tǒng)等信息吨拍。
? Accept：客戶端可識別的內(nèi)容類型列表羹饰，用于指定客戶端接收哪些類型的信息队秩。
? Accept-Encoding：客戶端可識別的數(shù)據(jù)編碼馍资。
? Accept-Language：表示瀏覽器所支持的語言類型。
? Connection：允許客戶端和服務(wù)器指定與請求/響應(yīng)連接有關(guān)的選項(xiàng)使兔。例如虐沥，這時為Keep-Alive則表示
保持連接置蜀。
? Transfer-Encoding：告知接收端為了保證報文的可靠傳輸盯荤，對報文采用了什么編碼方式秋秤。

3.響應(yīng)報頭：用于服務(wù)器傳遞自身信息的響應(yīng)灼卢。常見的響應(yīng)報頭如下所示 ? Location：用于重定向接收者到一個新的位置鞋真，常用在更換域名的時候涩咖。
? Server：包含服務(wù)器用來處理請求的系統(tǒng)信息繁莹，與User-Agent請求報頭是相對應(yīng)的咨演。

4.實(shí)體報頭：用來定義被傳送資源的信息薄风，其既可用于請求也可用于響應(yīng)遭赂。請求和響應(yīng)消息都可以傳送一
個實(shí)體嵌牺。常見的實(shí)體報頭如下所示
? Content-Type：發(fā)送給接收者的實(shí)體正文的媒體類型逆粹。
? Content-Lenght：實(shí)體正文的長度僻弹。
? Content-Language：描述資源所用的自然語言。
? Content-Encoding：實(shí)體報頭被用作媒體類型的修飾符蹋绽。它的值指示了已經(jīng)被應(yīng)用到實(shí)體正文的附加內(nèi)容的編碼芭毙，因而要獲得Content-Type報頭域中所引用的媒體類型，必須采用相應(yīng)的解碼機(jī)制卸耘。
? Last-Modified：實(shí)體報頭用于指示資源的最后修改日期和時間退敦。
? Expires：實(shí)體報頭給出響應(yīng)過期的日期和時間。

get/post方法的區(qū)別

get是獲取資源蚣抗，post是提供更新服務(wù)器上的資源

• 提交的數(shù)據(jù)

  get提交的數(shù)據(jù)一般放在URL之后用?分割，post提交數(shù)據(jù)基本都是放在body中

• 提交的數(shù)據(jù)大小是否有限制

  get提交數(shù)據(jù)大小有限制翰铡，因?yàn)闉g覽器對URL是有限制的钝域，不可能無限制的輸入一個URL地址。post提交數(shù)據(jù)锭魔，由于提交的是body例证，所以大小是沒有限制的

• 取得變量的值

get是通過Request.QueryString方式來獲得變量值，post是通過Request.Form來獲取變量值

• 安全問題

  get提交數(shù)據(jù)會帶來安全問題迷捧，比如提交賬戶密碼都會顯示在URL上

Cookie和Session

• Cookie技術(shù)是客戶端的解決方案织咧，Cookie就是由服務(wù)器發(fā)給客戶端的特殊信息，而這些信息以文本文件的方式存放在客戶端漠秋，然后客戶端每次向服務(wù)器發(fā)送請求的時候都會帶上這些特殊的信息烦感。Cookie是客戶端保存用戶信息的一種機(jī)制，用來記錄用戶的一些信息膛堤，也是實(shí)現(xiàn)Session的一種方式手趣。

  Cookie是由服務(wù)器端生成，發(fā)送給User-Agent（一般是web瀏覽器）肥荔，瀏覽器會將Cookie的key/value保存到某個目錄下的文本文件內(nèi)绿渣，下次請求同一網(wǎng)站時就發(fā)送該Cookie給服務(wù)器（前提是瀏覽器設(shè)置為啟用Cookie）。Cookie名稱和值可以由服務(wù)器端開發(fā)自己定義燕耿，對于JSP而言也可以直接寫入Sessionid中符，這樣服務(wù)器可以知道該用戶是否合法用戶以及是否需要重新登錄等。

• Session是另一種記錄客戶狀態(tài)的機(jī)制誉帅，不同的是Cookie保存在客戶端瀏覽器中淀散，而Session保存在服務(wù)器上右莱。客戶端瀏覽器訪問服務(wù)器的時候档插，服務(wù)器把客戶端信息以某種形式記錄在服務(wù)器上慢蜓。

  由于HTTP協(xié)議是無狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶的狀態(tài)時郭膛，就需要用某種機(jī)制來識別具體的用戶晨抡，這個機(jī)制就是Session.典型的場景比如購物車，當(dāng)你點(diǎn)擊下單按鈕時则剃，由于HTTP協(xié)議無狀態(tài)耘柱，所以并不知道是哪個用戶操作的，所以服務(wù)端要為特定的用戶創(chuàng)建了特定的Session棍现，用于標(biāo)識這個用戶调煎，并且跟蹤用戶，這樣才知道購物車?yán)锩嬗袔妆緯喊埂?chuàng)建了特定的Session的同時汛蝙，服務(wù)器會為該Session生成唯一的Session Id。Session被創(chuàng)建之后朴肺，就可以調(diào)用Session相關(guān)的方法往Session中增加內(nèi)容鸣剪。這個Session是保存在服務(wù)端的辕宏，有一個唯一標(biāo)識嫉嘀。在服務(wù)端保存Session的方法很多泉沾，內(nèi)存、數(shù)據(jù)庫鞍盗、文件都有需了。集群的時候也要考慮Session的轉(zhuǎn)移，在大型的網(wǎng)站般甲，一般會有專門的Session服務(wù)器集群肋乍，用來保存用戶會話，這個時候 Session 信息都是放在內(nèi)存的敷存。

  具體到Web中的Session指的就是用戶在瀏覽某個網(wǎng)站時墓造，從進(jìn)入網(wǎng)站到瀏覽器關(guān)閉所經(jīng)過的這段時間，也就是用戶瀏覽這個網(wǎng)站所花費(fèi)的時間锚烦。因此從上述的定義中我們可以看到觅闽，Session實(shí)際上是一個特定的時間概念。

  當(dāng)客戶端訪問服務(wù)器時涮俄，服務(wù)器根據(jù)需求設(shè)置Session蛉拙，將會話信息保存在服務(wù)器上，同時將標(biāo)示Session的SessionId傳遞給客戶端瀏覽器彻亲，瀏覽器將這個SessionId保存在內(nèi)存中孕锄，我們稱之為無過期時間的Cookie吮廉。瀏覽器關(guān)閉后，這個Cookie就會被清掉畸肆，它不會存在于用戶的Cookie臨時文件宦芦。以后瀏覽器再次發(fā)送請求都會額外加上這個Session Id，服務(wù)器會根據(jù)這個Session Id找到相應(yīng)的Session恼除，就能取得客戶端的數(shù)據(jù)信息。

  如果客戶端瀏覽器意外關(guān)閉曼氛，服務(wù)器保存的Session數(shù)據(jù)不是立即釋放豁辉，此時數(shù)據(jù)還會存在，只要我們知道那個SessionId,就可以繼續(xù)通過請求獲得此Session的信息舀患，因?yàn)榇藭r后臺的Session還存在徽级，當(dāng)然我們可以設(shè)置一個Session超時時間，一旦超過規(guī)定時間沒有客戶端請求時聊浅，服務(wù)器就會清除對應(yīng)SessionId的Session信息餐抢。

• 總結(jié)一下Cookie和Session的區(qū)別

  存放位置不同：Cookie存放在客戶端，Session存放在服務(wù)器

  存取方式不同：Cookie保存的是字符串低匙，Session中能夠存取任何類型的數(shù)據(jù)

  安全性（隱私策略）的不同：Cookie對客戶端是可見的旷痕，客戶端一些程序有可能去修改Cookie。Session存儲在服務(wù)端顽冶，對客戶端不可見欺抗，不存在敏感信息泄露風(fēng)險。

  有效期不同：一般Cookie有效期會設(shè)置很長時間强重，而Session依賴于當(dāng)中的一個id绞呈，如果把id設(shè)為-1，那么關(guān)閉了瀏覽器Session就會失效间景。

  對服務(wù)器造成的壓力不同：Session保存在服務(wù)端佃声，每個用戶都會產(chǎn)生一個Session，當(dāng)多個用戶并發(fā)訪問的時候就會產(chǎn)生很多Session倘要，會非常消耗內(nèi)存圾亏。Cookie保存在客戶端，不占用服務(wù)端資源封拧。所以多用戶并發(fā)的時候召嘶，Cookie是一個比較好的選擇。

HTTPS

HTTPS并不是一個單獨(dú)的協(xié)議哮缺，而是在加密連接(SSL/TLS)上的常規(guī)HTTP協(xié)議弄跌。通過在TCP和HTTP之間加入TLS (Transport Layer Security) 來加密。SSL協(xié)議尝苇，是一種安全傳輸協(xié)議铛只，TLS 是 SSL V3.0升級版

• HTTPS傳輸速度

  通信慢（相比HTTP還要處理TLS通信）

  SSL必須進(jìn)行加密處理（客戶端和服務(wù)器都要進(jìn)行加解密埠胖，需要消耗更多資源）

Https加密原理

加密算法的類型基本上分為了兩種：

• 對稱加密，加密用的密鑰和解密用的密鑰是同一個淳玩，比較有代表性的就是 DES直撤、AES 加密算法。對稱加密的優(yōu)點(diǎn)是計算速度快蜕着，缺點(diǎn)是密鑰需要在通訊的兩端共享谋竖。
• 非對稱加密，加密用的密鑰稱為公鑰承匣，解密用的密鑰稱為私鑰蓖乘。服務(wù)端生成配對的公鑰和私鑰，私鑰保存在客戶端韧骗，公鑰發(fā)送給客戶端嘉抒，客戶端使用公鑰加密明文傳輸給服務(wù)端，服務(wù)端使用私鑰解密袍暴。經(jīng)常使用到的 RSA 加密算法就是非對稱加密的些侍。

相比較對稱加密而言，非對稱加密安全性更高政模，但是加解密耗費(fèi)的時間更長岗宣，速度慢。HTTPS = HTTP + SSL淋样，HTTPS 的加密就是在 SSL 中完成的狈定。HTTPS采用的是對稱加密和非對稱加密的結(jié)合的方式保證安全，為了保證密鑰的安全习蓬，還引入了數(shù)字簽名和數(shù)字證書纽什。

數(shù)字簽名：用于驗(yàn)證傳輸?shù)膬?nèi)容是不是真實(shí)服務(wù)器發(fā)送的數(shù)據(jù)，發(fā)送的數(shù)據(jù)有沒有被篡改過躲叼，是非對稱加密的一種應(yīng)用場景芦缰。不過它是反過來用私鑰來加密，通過與之配對的公鑰來解密枫慷。

數(shù)字簽名的過程：

1.服務(wù)端把報文經(jīng)過Hash處理后生成摘要信息Digest让蕾，摘要信息使用私鑰加密之后就生成簽名，服務(wù)器把簽名連同報文一起發(fā)送給客戶端或听。

2.客戶端接收到數(shù)據(jù)后探孝，把簽名提取出來用公鑰解密，如果能正常解密出來Digest2誉裆，那么就能確認(rèn)是對方發(fā)的顿颅。

3.客戶端把報文Text提取出來做同樣的Hash處理，得到的摘要信息Digest1足丢，再與之前解密出來的Digest2對比粱腻，如果兩者相同表明內(nèi)容沒有被篡改過庇配。

數(shù)字證書：簡稱CA，它由權(quán)威機(jī)構(gòu)給某網(wǎng)站頒發(fā)的一種認(rèn)可憑證绍些，這個憑證是被大家(瀏覽器)所認(rèn)可的捞慌。數(shù)字證書主要是保證你使用的公鑰是真實(shí)服務(wù)器發(fā)送給你的。

https://juejin.im/post/5b48b0d7e51d4519962ea383#heading-23

HTTPS加密原理詳解可以看這：https://blog.csdn.net/guolin_blog/article/details/104546558

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

1.物理層
該層負(fù)責(zé)比特流在節(jié)點(diǎn)間的傳輸柬批，即負(fù)責(zé)物理傳輸啸澡。該層的協(xié)議既與鏈路有關(guān)，也與傳輸介質(zhì)有關(guān)氮帐。
其通俗來講就是把計算機(jī)連接起來的物理手段嗅虏。
2.數(shù)據(jù)鏈路層
該層控制網(wǎng)絡(luò)層與物理層之間的通信，其主要功能是如何在不可靠的物理線路上進(jìn)行數(shù)據(jù)的可靠傳遞揪漩。為了保證傳輸旋恼，從網(wǎng)絡(luò)層接收到的數(shù)據(jù)被分割成特定的可被物理層傳輸?shù)膸艨凇怯脕硪苿訑?shù)據(jù)的結(jié)構(gòu)包奄容，它不僅包括原始數(shù)據(jù)，還包括發(fā)送方和接收方的物理地址以及糾錯和控制信息产徊。其中的地址確定了幀將發(fā)送到何處昂勒，而糾錯和控制信息則確保幀無差錯到達(dá)。如果在傳送數(shù)據(jù)時舟铜，接收點(diǎn)檢測到所傳數(shù)據(jù)中有差錯戈盈，就要通知發(fā)送方重發(fā)這一幀。
3.網(wǎng)絡(luò)層
該層決定如何將數(shù)據(jù)從發(fā)送方路由到接收方谆刨。網(wǎng)絡(luò)層通過綜合考慮發(fā)送優(yōu)先權(quán)塘娶、網(wǎng)絡(luò)擁塞程度、服務(wù)
質(zhì)量以及可選路由的花費(fèi)來決定從一個網(wǎng)絡(luò)中的節(jié)點(diǎn) A 到另一個網(wǎng)絡(luò)中節(jié)點(diǎn) B 的最佳路徑痊夭。
4.傳輸層
該層為兩臺主機(jī)上的應(yīng)用程序提供端到端的通信刁岸。相比之下，網(wǎng)絡(luò)層的功能是建立主機(jī)到主機(jī)的通信她我。傳輸層有兩個傳輸協(xié)議：TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報協(xié)議）虹曙。其中，TCP是一個可靠的面向連接的協(xié)議番舆，UDP是不可靠的或者說無連接的協(xié)議酝碳。
5.應(yīng)用層
應(yīng)用程序收到傳輸層的數(shù)據(jù)后，接下來就要進(jìn)行解讀恨狈。解讀必須事先規(guī)定好格式疏哗，而應(yīng)用層就是規(guī)定
應(yīng)用程序的數(shù)據(jù)格式的。它的主要協(xié)議有HTTP禾怠、FTP沃斤、Telnet圣蝎、SMTP、POP3等衡瓶。

TCP三次握手四次揮手

相關(guān)報文段說明

ACK ： TCP協(xié)議規(guī)定徘公，只有ACK=1時有效，也規(guī)定連接建立后所有發(fā)送的報文的ACK必須為1

SYN(SYNchronization) ： 在連接建立時用來同步序號哮针。當(dāng)SYN=1而ACK=0時关面，表明這是一個連接請求報文。對方若同意建立連接十厢，則應(yīng)在響應(yīng)報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連接請求或連接接受報文等太。

FIN （finish）即完蛮放，終結(jié)的意思， 用來釋放一個連接包颁。當(dāng) FIN = 1 時，表明此報文段的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢蘑险，并要求釋放連接。

TCP三次握手的過程如下佃迄。

第一次握手：建立連接」笊伲客戶端發(fā)送連接請求報文段呵俏，將 SYN 設(shè)置為 1、Sequence Number（seq）為
x滔灶；接下來客戶端進(jìn)入SYN_SENT狀態(tài)普碎，等待服務(wù)端的確認(rèn)。
第二次握手：服務(wù)器收到客戶端的 SYN 報文段宽气，對 SYN 報文段進(jìn)行確認(rèn)随常，設(shè)置Acknowledgment
Number（ACK）為 x+1（seq+1）；同時自己還要發(fā)送 SYN 請求信息萄涯，將SYN設(shè)置為1绪氛、seq為y。服務(wù)端將上述所有信息放到SYN+ACK報文段中涝影，一并發(fā)送給客戶端枣察，此時服務(wù)端進(jìn)入SYN_RCVD狀態(tài)。
第三次握手：客戶端收到服務(wù)端的SYN+ACK報文段；然后將ACK設(shè)置為y+1序目，向服務(wù)端發(fā)送ACK報文段臂痕，這個報文段發(fā)送完畢后，客戶端和服務(wù)端都進(jìn)入ESTABLISHED （TCP連接成功）狀態(tài)猿涨，完成TCP的
三次握手。
當(dāng)客戶端和服務(wù)端通過三次握手建立了TCP連接以后叛赚，當(dāng)數(shù)據(jù)傳送完畢俺附，斷開連接時就需要進(jìn)行TCP的
四次揮手。

四次揮手的過程

第一次揮手：客戶端設(shè)置seq和ACK步鉴，向服務(wù)端發(fā)送一個FIN報文段氛琢。此時沮稚，客戶端進(jìn)入FIN_WAIT_1
狀態(tài)册舞，表示客戶端沒有數(shù)據(jù)要發(fā)送給服務(wù)端了调鲸。
第二次揮手：服務(wù)端收到了客戶端發(fā)送的FIN報文段，向客戶端回了一個ACK報文段即供。
第三次揮手：服務(wù)端向客戶端發(fā)送 FIN 報文段逗嫡，請求關(guān)閉連接驱证，同時服務(wù)端進(jìn)入LAST_ACK狀態(tài)恋腕。
第四次揮手：客戶端收到服務(wù)端發(fā)送的FIN報文段，向服務(wù)端發(fā)送ACK報文段获高，然后客戶端進(jìn)入TIME_WAIT狀態(tài)吻育。服務(wù)端收到客戶端的ACK報文段以后布疼，就關(guān)閉連接。此時严就，客戶端等待2MSL（最大報
文段生存時間）后依然沒有收到回復(fù)梢为，則說明服務(wù)端已正常關(guān)閉轰坊，這樣客戶端也可以關(guān)閉連接了肴沫。

TCP和UDP的區(qū)別

1、基于連接與無連接

2悲幅、對系統(tǒng)資源的要求（TCP較多汰具，UDP少）

3留荔、UDP程序結(jié)構(gòu)較簡單

4澜倦、流模式與數(shù)據(jù)報模式

5藻治、TCP保證數(shù)據(jù)正確性，UDP可能丟包

6恰聘、TCP保證數(shù)據(jù)順序晴叨，UDP不保證

如何設(shè)計在 UDP 上層保證 UDP 的可靠性傳輸

傳輸層無法保證數(shù)據(jù)的可靠傳輸，只能通過應(yīng)用層來實(shí)現(xiàn)了初厚。實(shí)現(xiàn)的方式可以參照TCP可靠性傳輸?shù)姆绞讲獭Ｈ绮豢紤]擁塞處理亚情，可靠UDP的簡單設(shè)計如下：

• 1哈雏、添加seq/ack機(jī)制裳瘪，確保數(shù)據(jù)發(fā)送到對端
• 2、添加發(fā)送和接收緩沖區(qū)黄伊，主要是用戶超時重傳还最。
• 3愈腾、添加超時重傳機(jī)制虱黄。

具體過程即是：送端發(fā)送數(shù)據(jù)時吮成，生成一個隨機(jī)seq=x粱甫，然后每一片按照數(shù)據(jù)大小分配seq。數(shù)據(jù)到達(dá)接收端后接收端放入緩存危纫，并發(fā)送一個ack=x的包种蝶，表示對方已經(jīng)收到了數(shù)據(jù)。發(fā)送端收到了ack包后搪桂，刪除緩沖區(qū)對應(yīng)的數(shù)據(jù)踢械。時間到后内列，定時任務(wù)檢查是否需要重傳數(shù)據(jù)背率。

目前有如下開源程序利用udp實(shí)現(xiàn)了可靠的數(shù)據(jù)傳輸退渗。分別為RUDP、RTP个粱、UDT

1都许、RUDP（Reliable User Datagram Protocol）

RUDP 提供一組數(shù)據(jù)服務(wù)質(zhì)量增強(qiáng)機(jī)制嫂冻，如擁塞控制的改進(jìn)桨仿、重發(fā)機(jī)制及淡化服務(wù)器算法等。

2钱雷、RTP（Real Time Protocol）

RTP為數(shù)據(jù)提供了具有實(shí)時特征的端對端傳送服務(wù)罩抗，如在組播或單播網(wǎng)絡(luò)服務(wù)下的交互式視頻音頻或模擬數(shù)據(jù)套蒂。

3、UDT（UDP-based Data Transfer Protocol）

UDT的主要目的是支持高速廣域網(wǎng)上的海量數(shù)據(jù)傳輸操刀。

關(guān)于RUDP馍刮、RTP、UDT的更多介紹請查看此處