計算機網絡

1. 網頁中輸入url，到渲染整個界面的整個過程，以及中間用了什麼協議？

過程分析：主要分爲三步

DNS解析。用戶輸入url後，須要經過DNS解析找到域名對應的ip地址，有了ip地址才能找到服務器端。首先會查找瀏覽器緩存，是否有對應的dns記錄。再繼續按照操做系統緩存—路由緩存—isp的dns服務器—根服務器的順序進行DNS解析，直到找到對應的ip地址。 客戶端（瀏覽器）和服務器交互。瀏覽器根據解析到的ip地址和端口號發起HTTP請求，請求到達傳輸層，這裏也就是TCP層，開始三次握手創建鏈接。服務器收到請求後，發送相應報文給客戶端（瀏覽器），客戶端收到相應報文並進行解析，獲得html頁面數據，包括html，js，css等。 客戶端（瀏覽器）解析html數據，構建DOM樹，再構造呈現樹（render樹），最終繪製到瀏覽器頁面上。 涉及到TCP/IP協議簇，包括DNS，TCP，IP，HTTP協議等等。

2. 具體介紹下TCP/IP

TCP/IP通常指的是TCP/IP協議簇，主要包括了多個不一樣網絡間實現信息傳輸涉及到的各類協議 主要包括如下幾層： **應用層：**主要提供數據和服務。好比HTTP，FTP，DNS等 **傳輸層：**負責數據的組裝，分塊。好比TCP，UDP等 **網絡層：**負責告訴通訊的目的地，好比IP等 **數據鏈路層：**負責鏈接網絡的硬件部分，好比以太網，WIFI等

TCP (傳輸控制協議) - 應用程序之間通訊。 當應用程序但願經過 TCP 與另外一個應用程序通訊時，它會發送一個通訊請求。這個請求必須被送到一個確切的地址。在雙方"握手"以後，TCP 將在兩個應用程序之間創建一個全雙工 (full-duplex) 的通訊。這個全雙工的通訊將佔用兩個計算機之間的通訊線路，直到它被一方或雙方關閉爲止。 IP (網際協議) - 計算機之間的通訊。IP 是無鏈接的通訊協議。它不會佔用兩個正在通訊的計算機之間的通訊線路。這樣，IP 就下降了對網絡線路的需求。每條線能夠同時知足許多不一樣的計算機之間的通訊須要。經過 IP，消息（或者其餘數據）被分割爲小的獨立的包，並經過因特網在計算機之間傳送。IP 負責將每一個包路由至它的目的地。

TCP的三次握手和四次揮手，爲何不是兩次握手？爲何揮手多一次呢？ 客戶端簡稱A，服務器端簡稱B 1）TCP創建鏈接須要三次握手 A向B表示想跟B進行鏈接（A發送syn包，A進入SYN B收到消息，表示我也準備好和你鏈接了（B收到syn包，須要確認syn包，而且本身也發送一個syn包，即發送了syn+ack包，B進入SYN_RECV狀態） A收到消息，並告訴B表示我收到你也準備鏈接的信號了（A收到syn+ack包，給B發送確認包ack，AB進入established狀態）開始鏈接。

2）TCP斷開鏈接須要四次揮手 A向B表示想跟B斷開鏈接（A發送fin，進入FIN_WAIT_1狀態） B收到消息，可是B消息沒發送完，只能告訴A我收到你的斷開鏈接消息（B收到fin，發送ack，進入CLOSE_WAIT狀態） 過一會，B數據發送完畢，告訴A，我能夠跟你斷開了（B發送fin，進入LAST_ACK狀態） A收到消息，告訴B，能夠他斷開（A收到fin，發送ack，B進入closed狀態）

3）爲何揮手多一次 其實正常的斷開和鏈接都是須要四次： A發消息給B B反饋給A表示正確收到消息 B發送消息給A A反饋給B表示正確收到消息。 可是鏈接中，第二步和第三步是能夠合併的，由於鏈接以前A和B是無聯繫的，因此沒有其餘狀況須要處理。而斷開的話，由於以前兩端是正常鏈接狀態，因此第二步的時候不能保證B以前的消息已經發送完畢，因此不能立刻告訴A要斷開的消息。這就是鏈接爲何能夠少一步的緣由。

4）爲何鏈接須要三次，而不是兩次 正常來講，我給你發消息，你告訴我能收到，不就表明咱們以前通訊是正常的嗎？ 簡單回答就是，TCP是雙向通訊協議，若是兩次握手，不能保證B發給A的消息正確到達。 TCP 協議爲了實現可靠傳輸， 通訊雙方須要判斷本身已經發送的數據包是否都被接收方收到， 若是沒收到， 就須要重發。

3. TCP是怎麼保證可靠傳輸的？

**序列號和確認號。**好比鏈接的一方發送一段80byte數據，會帶上一個序列號，好比101。接收方收到數據，回覆確認號181（180+1），這樣下一次發送消息就會從181開始發送了。 因此握手過程當中，好比A發送syn信號給B，初始序列號爲120，那麼B收到消息，回覆ack消息，序列號爲120+1。同時B發送syn信號給A，初始序列號爲256，若是收不到A的回覆消息，就會重發，不然丟失這個序列號，就沒法正常完成後面的通訊了。 這就是三次握手的緣由。

TCP/IP詳解—擁塞控制機制的四個階段

1．慢啓動階段

舊的TCP在啓動一個鏈接時會向網絡發送許多數據包,因爲一些路由器必須對數據包進行排隊，所以有可能耗盡存儲空間，從而致使TCP鏈接的吞吐量（throughput）急劇降低。避免這種狀況發生的算法就是慢啓動。當創建新的TCP鏈接時，擁塞窗口被初始化爲一個數據包大小（一個數據包缺省值爲536或512byte）。源端按cwnd大小發送數據，每收到一個ACK確認，cwnd就增長一個數據包發送量。顯然，cwnd的增加將隨RTT呈指數級(exponential)增加：1個、2個、4個、8個……。源端向網絡中發送的數據量將急劇增長。

2．擁塞避免階段

當發現超時或收到3個相同ACK確認幀時，網絡即發生擁塞（這是TCP Reno的作法，這一假定是基於由傳輸引發的數據包損壞和丟失的機率小於1%)。此時就進入擁塞避免階段。慢啓動閾值被設置爲當前cwnd的一半；超時時，cwnd被置爲1。若是cwnd≤ssthresh,則TCP從新進入慢啓動過程;若是cwnd>ssthresh，則TCP執行擁塞避免算法，cwnd在每次收到一個ACK時只增長1/cwnd個數據包（這裏將數據包大小segsize假定爲1）。

3．快速重傳和恢復階段

當數據包超時時，cwnd被設置爲1，從新進入慢啓動，這會致使過大地減少發送窗口尺寸，下降TCP鏈接的吞吐量。所以快速重傳和恢復就是在源端收到3個或3個以上重複ACK時，就判定數據包已經被丟失，並重傳數據包，同時將ssthresh設置爲當前cwnd的一半，而沒必要等到RTO超時。圖2和圖3反映了擁塞控制窗口隨時間在四個階段的變化狀況。

4. TCP和UDP的區別？

TCP提供的是面向鏈接，可靠的字節流服務。即客戶和服務器交換數據前，必須如今雙方之間創建一個TCP鏈接（三次握手），以後才能傳輸數據。而且提供超時重發，丟棄重複數據，檢驗數據，流量控制等功能，保證數據能從一端傳到另外一端。

UDP 是一個簡單的面向數據報的運輸層協議。它不提供可靠性，只是把應用程序傳給IP層的數據報發送出去，可是不能保證它們能到達目的地。因爲UDP在傳輸數據報前不用再客戶和服務器之間創建一個鏈接，且沒有超時重發等機制，因此傳輸速度很快。

因此總結下來就是：

TCP 是面向鏈接的，UDP 是面向無鏈接的 TCP 數據報頭包括序列號，確認號，等等。相比之下UDP程序結構較簡單。 TCP 是面向字節流的，UDP 是基於數據報的 TCP 保證數據正確性，UDP 可能丟包 TCP 保證數據順序，UDP 不保證 能夠看到TCP適用於穩定的應用場景，他會保證數據的正確性和順序，因此通常的瀏覽網頁，接口訪問都使用的是TCP傳輸，因此纔會有三次握手保證鏈接的穩定性。 而UDP是一種結構簡單的協議，不會考慮丟包啊，創建鏈接等。優勢在於數據傳輸很快，因此適用於直播，遊戲等場景。

5. HTTP的幾種請求方法具體介紹

常見的有四種：

GET 獲取資源，沒有body，冪等性 POST 增長或者修改資源，有body PUT 修改資源，有body，冪等性 DELETE 刪除資源，冪等性

經常使用狀態碼

主要分爲五種類型： 1開頭， 表明臨時性消息，好比100（繼續發送） 2開頭， 表明請求成功，好比200（OK） 3開頭， 表明重定向，好比304（內容無改變） 4開頭， 表明客戶端的一些錯誤，好比403（禁止訪問） 5開頭， 表明服務器的一些錯誤，好比500

6.請回答一個 TCP 鏈接上面能發多少個 HTTP 請求？

若是維持鏈接，一個 TCP 鏈接是能夠發送多個 HTTP 請求的。

7.一個 TCP 鏈接中 HTTP 請求發送能夠一塊兒發送麼（好比一塊兒發三個請求，再三個響應一塊兒接收）？

HTTP/1.1 存在一個問題，單個 TCP 鏈接在同一時刻只能處理一個請求，意思是說：兩個請求的生命週期不能重疊，任意兩個 HTTP 請求從開始到結束的時間在同一個 TCP 鏈接裏不能重疊。

8.Get請求和Post請求的區別

Get請求比Post請求效率高，Post請求須要服務器返回100再發送數據處理，Get請求直接是經過URL。 1，GET在瀏覽器回退是無害的，而POST會再次提交請求 2，GET產生的URL地址能夠被網址收藏BOOKMARK，而POST不能夠 3，GET請求只能進行url編碼，而post支持多種編碼形式 4，get請求參數會被完整保留在瀏覽器歷史記錄裏，而post中的參數不會被保留 5，get請求在url中傳遞的參數是有長度限制的不超過4k，而post沒有 6，對參數的數據類型，get只接受ASCII類型，而post沒有限制 7，get比post更不安全，由於參數直接暴露在url上，因此不能用傳遞敏感信息 8，get參數經過url傳遞，post放在request body報文體中 9，get產生一個tcp數據包，post產生兩個tcp數據包

9. Http和Https

一、https協議須要到CA申請證書，通常免費證書較少，於是須要必定費用。 二、http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl/tls加密傳輸協議。 三、http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。 四、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL/TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

10.什麼是HTTP的長鏈接和短鏈接？

HTTP1.1規定了默認保持長鏈接（HTTP persistent connection ，也有翻譯爲持久鏈接），數據傳輸完成了保持TCP鏈接不斷開（不發RST包、不四次握手），等待在同域名下繼續用這個通道傳輸數據；相反的就是短鏈接。