網絡相關知識

1.當用戶輸入url後，期間發生的事情？

1）若是地址是一個IP地址，會直接找該IP對應的網絡計算機。若是不是IP地址，則經過DNS（域名系統）將該地址解析成IP地址，再去網絡上找對應的計算機。DNS服務器自己也IP，你的網絡設置包含DNS服務器的IP。
注：DNS解析完成，查找對應的網絡計算機時，可能電腦直接詢問的DNS服務器可能沒有對應的IP，那當前DNS服務器就會向它的上級服務器詢問，上級服務器也可能沒有，就依次一層層向上找，最高查找到根節點，找到或者一直找不到爲止。
2）若是地址不包含端口號，協議的默認端口號爲80。若是指定了端口好，那麼使用指定的端口號。
3）IP和端口號都肯定後，發起請求，鏈接對應的網絡計算機和對應的端口。
4）根據http協議要求，須要把大量的請求信息放在請求頭上，發送給對應的服務器。包括請求的資源路徑、請求者身份等信息。
5）服務器響應請求，將數據返回給瀏覽器。瀏覽器接受到html類型的代碼，開始渲染頁面，放遇到內嵌資源地址時，再次向瀏覽器發送請求來獲取這些資源。（若是資源路徑指示的資源不存在，服務器就會返回404錯誤。）
6）將渲染好的頁面顯示出來，並開始響應用戶的操做。

 

域名解析 --> TCP3次握手 --> 發起http請求 --> 服務器響應http請求並傳輸數據 –>  瀏覽器解析並渲染呈現給用戶 –> TCP4次揮手

 

2.OSI七層模型：

1.物理層 ：鏈接線纜的標準

2.數據鏈路層 ：加mac地址的標記（網卡的物理地址）  802.3，802.2

3.網絡層：源ip地址，目的ip地址    ip

4.傳輸層 ： 源端口，目的端口     tcop/udp

5.會話層 ：通訊狀態           操做系統

6.表示層 ： 編碼方式          ASCII

7.應用層 ： http協議就是應用層的一種協議

 

3.域名解析：從 www.toutiao.com 到 202.108.250.213 的轉換工做稱爲域名解析，域名解析須要由專門的域名解析服務器來完成，DNS就是進行域名解析的服務器

當用戶在瀏覽器輸入https://www.cnblogs.com/時，瀏覽器會對此域名或主機進行解析，獲得對應的IP地址，那麼它時怎麼進行域名解析的呢？

一、首先先去本機hosts文件查找此FQDN沒有沒定義的指向所在的IP地址條目，若是找到，就結束解析

二、若是沒有找到，回去瀏覽器器自己DNS緩存裏去尋找，找打結束解析

三、沒有找到，會去本機配置的首選DNS服務器查詢，通常這是三大運營商提供的，經過UTP53端口發起請求，這個請求是遞歸查詢，DNS服務器收到請求後，會查詢自身緩存，找到條目而且沒有過時，就返回給用戶，結束解析。若是沒有找到，它會去找根服務器，全球13個根服務器（根服務器地址本機DNS服務器內置），詢問根服務器（你知不知道一個域名叫「www.cnblogs.com」的IP地址)，根回覆說，(我不知道此域名的IP地址，但我知道com域的IP地址，你去詢問它吧)，因而運行商提供的DNS服務器就去詢問com這個域，（你知不知道一個叫「www.cnblogs.com」域名IP地址），com域回答你說，（我不知道此域名的IP地址，但我知道「cnblogs.com域的IP地址，你去問他吧「），這是運行商DNS服務器，對cnblogs.com域發起請求詢問，（你知不知道一個叫」www.cnblogs.com「域的IP地址，它一查，發現此域，就是它負責的，就會對你說，此域是我負責的，它的IP是X.X.X.X這時運行商DNS服務器拿到地址，就會返回客戶主機內核，內核再返回給瀏覽器，到此解析結束，進行下一步。

 

域名等級：主機名.次級域名.頂級域名.根域名（www.example.com.root）

TCP3次握手

瀏覽器拿到域名對應的IP後，會拿一個隨機端口向WEB服務程序80端口發起TCP請求連接

過程

第一次握手：創建鏈接，客戶端將SYN標記爲1，seq標記爲x，並將SYN包發送到服務器，並進入SYN_SEND狀態，等待服務器確認；

第二次握手：服務器收到SYN，知道客戶端要創建連接，同時向客戶端也發送一個SYN包（SYN=1）和一個ACK包(ACK=1)，隨機產生一個數seq=y，ack=x+1（客戶端的seq值x加1），來確認客戶端的SYN，並進入SYN_RECV；

第三次握手：客戶端收到服務器發來的SYN+ACK後，確認ack值，並回復服務器端一個ACK確認，發送完畢後，雙方進入ESTABLISHED狀態。

三次握手成功後，開始傳輸數據。

一個完整的三次握手也就是 請求---應答---再次確認

連接創建成功後，就要開始下一步，傳輸數據。

 

HTTP請求相應處理

一、創建TCP鏈接：

接收或拒絕鏈接請求

發送請求報文：報文由請求頭，首部行，實體主體

二、接收請求：

接收客戶端發來的請求報文中的信息對某資源的一次請求的過程

Web訪問響應模型（Web I/O）

1）單進程I/O模型：

啓動一個進程處理用戶請求，並且一次只處理一個，多個請求被串行響應

2）多進程I/O模型：

並行啓動多個進程,每一個進程響應一個鏈接請求

3）複用I/O結構：

啓動一個進程，同時響應N個鏈接請求

實現方法：    多線程模型和事件驅動

      多線程模型： 一個進程生成N個線程，每線程響應一個鏈接請求

      事件驅動：    一個進程處理N個請求

4）複用的多進程I/O模型：

啓動M個進程，每一個進程響應N個鏈接請求，同時接收M*N個請求。

三、處理請求：

服務器對請求報文進行解析，並獲取請求的資源及請求方法等相關信息，根據方法，資源，首部和可選的主體部分對請求進行處理。HTTP經常使用請求方式，Method
GET、POST、HEAD、PUT、DELETE、TRACE、OPTIONS。

四、訪問資源：

服務器獲取請求報文中請求的資源web服務器，即存放了web資源的服務器，負責向請求者提供對方請求的靜態資源，或動態運行後生成的資源

資源放在服務端特定的目錄下

備註：經過MAC地址和端口號肯定具體的應用程序

六、發送響應報文

向客戶端回覆報文

七、記錄日誌：

最後，當事務結束時，Web服務器會在日誌文件中添加一個條目，來描述已執行的事務

 

四次揮手

1. 客戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。
2. 服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3. 客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這以前還須要接受服務器發送的最後的數據）。
4. 服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
5. 客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP鏈接尚未釋放，必須通過（最長報文段壽命）的時間後當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
6. 服務器只要收到了客戶端發出的確認，當即進入CLOSED狀態。一樣，撤銷TCB後，就結束了此次的TCP鏈接。能夠看到，服務器結束TCP鏈接的時間要比客戶端早一些。

 

1．爲何創建鏈接協議是三次握手，而關閉鏈接倒是四次握手呢？

這是由於服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它能夠把ACK和SYN（ACK起應答做用，而SYN起同步做用）放在一個報文裏來發送。但關閉鏈接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你全部的數據都所有發送給對方了，因此你能夠未必會立刻會關閉SOCKET,也即你可能還須要發送一些數據給對方以後，再發送FIN報文給對方來表示你贊成如今能夠關閉鏈接了，因此它這裏的ACK報文和FIN報文多數狀況下都是分開發送的.

2.爲何須要三次握手？

若是客戶端遲遲沒有收到服務器返回確認報文，這時會放棄鏈接，從新啓動一條鏈接請求，但問題是,
服務器不知道客戶端沒有收到，因此他會收到兩個鏈接，浪費鏈接開銷。若是每次都是這樣，就會浪費多個鏈接開銷。

爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤。