一. OSI與TCP/IP各層的結構與功能,都有哪些協議?

OSI，TCP/IP，五層協議的體系結構，以及各層協議

1.1應用層

應用層(application-layer）的任務是通過應用進程間的交互來完成特定網絡應用
HTTP協議

超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最爲廣泛的一種網絡協議。所有的
WWW（萬維網） 文件都必須遵守這個標準。設計 HTTP 最初的目的是爲了提供一種發佈和接收 HTML 頁面的方法。

1.2運輸層

傳輸層負責將上層數據分段並提供端到端的、可靠的或不可靠的傳輸。此外，傳輸層還要處理端到端的差錯控制和流量控制問題。

傳輸控制協議 TCP（Transmission Control Protocol）–提供面向連接的，可靠的數據傳輸服務。
用戶數據協議UDP（User Datagram Protocol）–提供無連接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）。

1.3網絡層

實現兩個主機系統之間的數據透明傳送.網絡層的任務就是選擇合適的網間路由和交換結點， 確保數據及時傳送。
主要協議有:

IP協議（Internet Protocol，因特網互聯協議）;

ICMP協議（Internet Control Message Protocol，因特網控制報文協議）;

ARP協議（Address Resolution Protocol，地址解析協議）可看成是跨網絡層和鏈路層的協議;

RARP協議（Reverse Address Resolution Protocol，逆地址解析協議）。

1.4數據鏈路層

1> 數據鏈路層爲網絡層提供可靠的數據傳輸；

2> 基本數據單位爲幀；

3> 主要的協議：以太網協議；

4> 兩個重要設備名稱：網橋和交換機。

1.5物理層

該層爲上層協議提供了一個傳輸數據的可靠的物理媒體。簡單的說，物理層確保原始的數據可在各種物理媒體上傳輸.

信息在網絡中傳輸過程

1、某進程(也就是在應用層)準備好待傳輸數據，若目的地址是域名則要先通過DNS解析成IP地址

2、交付到運輸層(TCP/UDP層)，運輸層對數據進行適當的分組等操作，後對每一個分組數組加上首部形成報文段(或用戶數據報)首部包括源地址、源端口、目的地址、目的端口和一些其他的諸如校驗和等數據

3、交付到網際層(IP層)，對分組數據加上首部形成IP數據報，首部包括源地址、目的地址(跟運輸層的目的地址不同，運輸層的目的地址是數據要傳送的最終地址，而該目的地址是通過路由表信息得出，是該數據下一步該轉移的目的計算機)和校驗和等數據

4、交付到數據鏈路層(mac層)，先是對把數據封裝成幀(也就是添加首部[SOH]和尾部[EOT])，然後進行透明傳輸(也就是封裝的數據裏面，如果出現首部SOH和尾部EOT這樣的數據，對其進行轉義，也就是加上ESC轉義字符，這種方法稱爲字節/字符填充)

5、交付到物理層，根據數據鏈路層的mac知道要傳輸到目的計算機，通過特定的傳輸介質傳送到下一個地址

6、若源主機與最終目的主機在同一個網段，則該地址是最終的目的主機，開始接收數據，進入第7步驟，若源主機和最終目的主機不在同一個網段，進入第11步驟

7、交付到數據鏈路層，對數據進行卸裝，該層會對接收的數據進行差錯檢測，有差錯的數據都會被丟棄

8、交付到IP層，解幀校驗

9、交付到運輸層，在該主機上，根據端口找到對應的應用，當使用的TCP協議時，提供一種面向連接的可靠的傳輸服務，可以說是建立了一個虛擬通道，源主機的數據通過該虛擬通道進行傳輸；若是使用的UDP協議時，提供一種面向的非連接的盡最大努力的不可靠的傳輸服務，數據傳輸快，但是無法保證數據100%傳輸。

10、建立了傳輸連接後，應用開始接收數據，發送方數據和接收方都必須滿足相同的標準應用層協議，如http、ftp、smtp等，通過標準協議應用即可正確的接收源主機發送過來的數據。

11、該計算機不是最終主機，那該計算機就是路由器也就是用於轉發分組數據的中轉站，首先接收數據的處理同步驟7和8一樣，然後接下來的流程又是如同步驟3,

12、如此循環直至找到最終主機，將數據傳送到目的應用

二 .TCP 三次握手和四次揮手

2.1TCP三次握手和四次揮手詳解

首先了解TCP首部結構
1.源端口和目的端口，各佔2個字節，分別寫入源端口和目的端口；
2.序號, 佔4個字節， TCP連接中傳送的字節流中的每個字節都按順序編號.
3.確認號，佔4個字節，是期望收到對方下一個報文的第一個數據字節的序號。
4.數據偏移，佔4位，它指出TCP報文的數據距離TCP報文段的起始處有多遠；
5.確認ACK，僅當ACK=1時，確認號字段纔有效。TCP規定，在連接建立後所有報文的傳輸都必須把ACK置1；
6.同步SYN，在連接建立時用來同步序號。當SYN=1，ACK=0，表明是連接請求報文，若同意連接，則響應報文中應該使SYN=1，ACK=1；
7.終止FIN，用來釋放連接。當FIN=1，表明此報文的發送方的數據已經發送完畢，並且要求釋放；

最開始的時候客戶端和服務器都是處於CLOSED狀態。主動打開連接的爲客戶端，被動打開連接的是服務器。

1.TCP服務器進程先創建傳輸控制塊TCB，時刻準備接受客戶進程的連接請求，此時服務器就進入了LISTEN（監聽）狀態；
2.TCP客戶進程也是先創建傳輸控制塊TCB，然後向服務器發出連接請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端進程進入了 SYN-SENT（同步已發送狀態）狀態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但需要消耗掉一個序號。
3.TCP服務器收到請求報文後，如果同意連接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲自己初始化一個序列號 seq=y，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，但是同樣要消耗一個序號。
4.TCP客戶進程收到確認後，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，自己的序列號seq=x+1，此時，TCP連接建立，客戶端進入ESTABLISHED（已建立連接）狀態。TCP規定，ACK報文段可以攜帶數據，但是如果不攜帶數據則不消耗序號。
5.當服務器收到客戶端的確認後也進入ESTABLISHED狀態，此後雙方就可以開始通信了。

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連接還沒有釋放，必須經過 2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
6.服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。

2.2爲什麼是三次握手和四次揮手

三次握手:爲了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤.(如果在連接過程中,客戶端發出的連接請求報文段在網絡中滯留,在連接釋放後的某個時間發送到了服務端,服務端以爲是建立連接請求,於是發出確認,如果不是三次握手,服務端就會一直等着客戶端發來數據,造成網絡資源浪費,三次握手就很好的解決了此問題.)
四次揮手:例子:舉個例子：A 和 B 打電話，通話即將結束後，A 說「我沒啥要說的了」，B回答「我知道了」，但是 B 可能還會有要說的話，A 不能要求 B 跟着自己的節奏結束通話，於是 B 可能又巴拉巴拉說了一通，最後 B 說「我說完了」，A 回答「知道了」，這樣通話纔算結束。

2.3.爲什麼客戶端最後還要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允許不同的實現可以設置不同的MSL值。

第一，保證客戶端發送的最後一個ACK報文能夠到達服務器，因爲這個ACK報文可能丟失，站在服務器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端還沒有給我回應，應該是我發送的請求斷開報文它沒有收到，於是服務器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接着給出迴應報文，並且會重啓2MSL計時器。

第二，防止類似與「三次握手」中提到了的「已經失效的連接請求報文段」出現在本連接中。客戶端發送完最後一個確認報文後，在這個2MSL時間中，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。

2.4 TCP,UDP 協議的區別

2.5 TCP 協議如何保證可靠傳輸

1.應用數據被分割成 TCP 認爲最適合發送的數據塊。
2.TCP 給發送的每一個包進行編號，接收方對數據包進行排序，把有序數據傳送給應用層。
3.校驗和： TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。
4.TCP 的接收端會丟棄重複的數據。
5.流量控制： TCP 連接的每一方都有固定大小的緩衝空間，TCP的接收端只允許發送端發送接收端緩衝區能接納的數據。當接收方來不及處理髮送方的數據，能提示發送方降低發送的速率，防止包丟失。TCP 使用的流量控制協議是可變大小的滑動窗口協議。 （TCP 利用滑動窗口實現流量控制）
6.擁塞控制： 當網絡擁塞時，減少數據的發送。
7.ARQ協議： 也是爲了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認。在收到確認後再發下一個分組。
8.超時重傳： 當 TCP 發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。

三.在瀏覽器中輸入url地址 ->> 顯示主頁的過程

總體來說分爲以下幾個過程:

1.DNS解析 2.TCP連接 3.發送HTTP請求 4.服務器處理請求並返回HTTP報文 5.瀏覽器解析渲染頁面 6.連接結束