1.大綱web
2.請簡述TCP\UDP的區別瀏覽器
TCP和UDP是OSI模型中的運輸層中的協議。TCP提供可靠的通訊傳輸,而UDP則常被用於讓廣播和細節控制交給應用的通訊傳輸。緩存
二者的區別大體以下:安全
若是還不是太瞭解這二者的區別,點擊閱讀:TCP與UDP的區別 - yipiankongbai的專欄服務器
3.請簡單說一下你瞭解的端口及對應的服務?網絡
4.標誌位併發
5.說一說TCP的三次握手分佈式
在TCP/IP協議中,TCP協議提供可靠的鏈接服務,鏈接是經過三次握手進行初始化的。三次握手的目的是同步鏈接雙方的序列號和確認號並交換 TCP窗口大小信息。加密
6.有哪些私有(保留)地址?spa
A類地址範圍:0.0.0.0到127.255.255.255。
B類地址範圍:128.0.0.0到191.255.255.255
C類地址範圍:192.0.0.0到223.255.255.255。
7.IP地址分爲哪幾類?簡單說一下各個分類
IPv6 -- 採用128bit,首部固定部分爲40字節。
8.在瀏覽器中輸入網址以後執行會發生什麼?
9.簡單解釋一些ARP協議的工做過程
ARP是地址解析協議,簡單語言解釋一下工做原理。
1:首先,每一個主機都會在本身的ARP緩衝區中創建一個ARP列表,以表示IP地址和MAC地址之間的對應關係。
2:當源主機要發送數據時,首先檢查ARP列表中是否有對應IP地址的目的主機的MAC地址,若是有,則直接發送數據,若是沒有,就向本網段的全部主機發送ARP數據包,該數據包包括的內容有:源主機 IP地址,源主機MAC地址,目的主機的IP 地址。
3:當本網絡的全部主機收到該ARP數據包時,首先檢查數據包中的IP地址是不是本身的IP地址,若是不是,則忽略該數據包,若是是,則首先從數據包中取出源主機的IP和MAC地址寫入到ARP列表中,若是已經存在,則覆蓋,而後將本身的MAC地址寫入ARP響應包中,告訴源主機本身是它想要找的MAC地址。
4:源主機收到ARP響應包後。將目的主機的IP和MAC地址寫入ARP列表,並利用此信息發送數據。若是源主機一直沒有收到ARP響應數據包,表示ARP查詢失敗。
廣播發送ARP請求,單播發送ARP響應。
10.OSI七層模型
物理層:經過媒介傳輸比特,肯定機械及電氣規範(比特Bit)
數據鏈路層:將比特組裝成幀和點到點的傳遞(幀Frame)
網絡層:負責數據包從源到宿的傳遞和網際互連(包PackeT)
傳輸層:提供端到端的可靠報文傳遞和錯誤恢復(段Segment)
會話層:創建、管理和終止會話(會話協議數據單元SPDU)
表示層:對數據進行翻譯、加密和壓縮(表示協議數據單元PPDU)
應用層:容許訪問OSI環境的手段(應用協議數據單元APDU)
11.四層模型
TCP/IP分層(4層):網絡接口層、 網際層、運輸層、 應用層。
12.HTTP 協議包括哪些請求?
13.各類協議
ICMP協議: 因特網控制報文協議。它是TCP/IP協議族的一個子協議,用於在IP主機、路由器之間傳遞控制消息。
TFTP協議: 是TCP/IP協議族中的一個用來在客戶機與服務器之間進行簡單文件傳輸的協議,提供不復雜、開銷不大的文件傳輸服務。
HTTP協議: 超文本傳輸協議,是一個屬於應用層的面向對象的協議,因爲其簡捷、快速的方式,適用於分佈式超媒體信息系統。
DHCP協議: 動態主機配置協議,是一種讓系統得以鏈接到網絡上,並獲取所須要的配置參數手段。
NAT協議:網絡地址轉換屬接入廣域網(WAN)技術,是一種將私有(保留)地址轉化爲合法IP地址的轉換技術,
DHCP協議:一個局域網的網絡協議,使用UDP協議工做,用途:給內部網絡或網絡服務供應商自動分配IP地址,給用戶或者內部網絡管理員做爲對全部計算機做中央管理的手段。
14.四次揮手
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鏈接的時間要比客戶端早一些。
15.爲何鏈接的時候是三次握手,關閉的時候倒是四次握手?
由於當Server端收到Client端的SYN鏈接請求報文後,能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的,SYN報文是用來同步的。可是關閉鏈接時,當Server端收到FIN報文時,極可能並不會當即關閉SOCKET,因此只能先回復一個ACK報文,告訴Client端,"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了,我才能發送FIN報文,所以不能一塊兒發送。故須要四步握手。
16.爲何TIME_WAIT狀態須要通過2MSL(最大報文段生存時間)才能返回到CLOSE狀態?
雖然按道理,四個報文都發送完畢,咱們能夠直接進入CLOSE狀態了,可是咱們必須假象網絡是不可靠的,有能夠最後一個ACK丟失。因此TIME_WAIT狀態就是用來重發可能丟失的ACK報文。在Client發送出最後的ACK回覆,但該ACK可能丟失。Server若是沒有收到ACK,將不斷重複發送FIN片斷。因此Client不能當即關閉,它必須確認Server接收到了該ACK。Client會在發送出ACK以後進入到TIME_WAIT狀態。Client會設置一個計時器,等待2MSL的時間。若是在該時間內再次收到FIN,那麼Client會重發ACK並再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片斷在網絡中最大的存活時間,2MSL就是一個發送和一個回覆所需的最大時間。若是直到2MSL,Client都沒有再次收到FIN,那麼Client推斷ACK已經被成功接收,則結束TCP鏈接。
17.爲何不能用兩次握手進行鏈接?
3次握手完成兩個重要的功能,既要雙方作好發送數據的準備工做(雙方都知道彼此已準備好),也要容許雙方就初始序列號進行協商,這個序列號在握手過程當中被髮送和確認。
如今把三次握手改爲僅須要兩次握手,死鎖是可能發生的。做爲例子,考慮計算機S和C之間的通訊,假定C給S發送一個鏈接請求分組,S收到了這個分組,併發 送了確認應答分組。按照兩次握手的協定,S認爲鏈接已經成功地創建了,能夠開始發送數據分組。但是,C在S的應答分組在傳輸中被丟失的狀況下,將不知道S 是否已準備好,不知道S創建什麼樣的序列號,C甚至懷疑S是否收到本身的鏈接請求分組。在這種狀況下,C認爲鏈接還未創建成功,將忽略S發來的任何數據分 組,只等待鏈接確認應答分組。而S在發出的分組超時後,重複發送一樣的分組。這樣就造成了死鎖。
18.若是已經創建了鏈接,可是客戶端忽然出現故障了怎麼辦?
TCP還設有一個保活計時器,顯然,客戶端若是出現故障,服務器不能一直等下去,白白浪費資源。服務器每收到一次客戶端的請求後都會從新復位這個計時器,時間一般是設置爲2小時,若兩小時尚未收到客戶端的任何數據,服務器就會發送一個探測報文段,之後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應,服務器就認爲客戶端出了故障,接着就關閉鏈接。
19.報文
20.http與https
一、https協議須要到ca申請證書,通常免費證書較少,於是須要必定費用。
二、http是超文本傳輸協議,信息是明文傳輸,https則是具備安全性的ssl加密傳輸協議。
三、http和https使用的是徹底不一樣的鏈接方式,用的端口也不同,前者是80,後者是443。
四、http的鏈接很簡單,是無狀態的;HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,比http協議安全。