1、OSI,TCP/IP,五層協議的體系結構,以及各層協議
OSI分層 (7層):物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。
TCP/IP分層(4層):網絡接口 網絡層、運輸層、 應用層。
TCP/IP五層協議 (5層):物理層、數據鏈路層、網絡層、運輸層、 應用層。
每一層的協議如下:
物理層:RJ45、CLOCK、IEEE802.3 (中繼器,集線器,網關)
數據鏈路:PPP、FR、HDLC、VLAN、MAC (網橋,交換機)
網絡層:IP(Internet Protocol,因特網互聯協議)、ICMP(Internet Control Message Protocol,因特網控制報文協議)、ARP(Address Resolution Protocol,地址解析協議)、RARP(Reverse Address Resolution Protocol,逆地址解析協議)、OSPF、IPX、RIP、IGRP、 (路由器)
傳輸層:TCP(Transmission Control Protocol,傳輸控制協議)、UDP(User Datagram Protocol,用戶數據報協議)、SPX
會話層:NFS、SQL、NETBIOS、RPC
表示層:JPEG、MPEG、ASII
應用層:FTP(文件傳送協議)、DNS(域名解析協議)、Telnet(遠程登錄協議)、SMTP(郵件傳送協議)、HTTP(Hyper Text Transfer Protocol)、WWW、NFS
每一層說明及作用:
(1)物理層:
作用:確保原始的數據可在各種物理媒體上傳輸
(2)數據鏈路層:
數據鏈路層最基本的服務是將源自網絡層來的數據可靠地傳輸到相鄰節點的目標機網絡層。為達到這一目的,數據鏈路必須具備一系列相應的功能,主要有:如何將數據組合成數據塊,在數據鏈路層中稱這種數據塊為幀(frame),幀是數據鏈路層的傳送單位;如何控制幀在物理信道上的傳輸,包括如何處理傳輸差錯,如何調節發送速率以使與接收方相匹配;以及在兩個網絡實體之間提供數據鏈路通路的建立、維持和釋放的管理。數據鏈路層在不可靠的物理介質上提供可靠的傳輸。
作用:物理地址尋址、數據的成幀、流量控制、數據的檢錯、重發等。
(3)網絡層:
網絡層的目的是實現兩個主機系統之間的數據透明傳送。它提供的服務使傳輸層不需要了解網絡中的數據傳輸和交換技術。如果您想用盡量少的詞來記住網絡層,那就是“路徑選擇、路由及邏輯尋址”。
作用:尋址和路由選擇、連接的建立、保持和終止等。
(4)傳輸層:
第一個端到端,即主機到主機的層次。傳輸層負責將上層數據分段並提供端到端的、可靠的或不可靠的傳輸。此外,傳輸層還要處理端到端的差錯控制和流量控制問題。
傳輸層的任務是根據通信子網的特性,最佳的利用網絡資源,為兩個端系統的會話層之間,提供建立、維護和取消傳輸連接的功能,負責端到端的可靠數據傳輸。在這一層,信息傳送的協議數據單元稱為段或報文。
作用:為應用進程之間提供端到端的邏輯通信。
注:網絡層只是根據網絡地址將源結點發出的數據包傳送到目的結點,而傳輸層則負責將數據可靠地傳送到相應的端口。
(5)會話層:
會話層管理主機之間的會話進程,即負責建立、管理、終止進程之間的會話。會話層還利用在數據中插入校驗點來實現數據的同步。
作用:建立、管理、終止進程之間的會話
(6)表示層:
表示層對上層數據或信息進行變換以保證一個主機應用層信息可以被另一個主機的應用程序理解。表示層的數據轉換包括數據的加密、壓縮、格式轉換等。
作用:對數據進行翻譯、加密和壓縮
(7)應用層:
是最靠近用戶的OSI層,為用戶的應用程序提供網絡服務的接口。將用戶的操作通過應用程序轉換成為服務,並匹配一個相應的服務協議發送給傳輸層。
作用:將用戶的操作通過應用程序轉換成為服務,並匹配一個相應的服務協議發送給傳輸層。
注:我們在傳輸數據時,可以只使用(傳輸層)TCP/IP協議,但是那樣的話,如果沒有應用層,便無法識別數據內容,如果想要使傳輸的數據有意義,則必須使用到應用層協議。
2、傳輸層協議與網絡層協議的區別?
網絡層協議負責的是提供主機間的邏輯通信
運輸層協議負責的是提供進程間的邏輯通信
3、數據鏈路層協議可能提供的服務有那些?
成幀、鏈路訪問、透明傳輸、可靠交付、流量控制、差錯檢測、差錯糾正、半雙工和全雙工。最重要的是幀定界(成幀)、透明傳輸以及差錯檢測。
4、TCP和UDP的區別
TCP 和UDP協議屬於傳輸層協議。
5、TCP對應的協議和UDP對應的協議
TCP對應的協議:
FTP:定義了文件傳輸協議,使用21端口。
Telnet:一種用於遠程登陸的端口,使用23端口,用戶可以以自己的身份遠程連接到計算機上,可提供基於DOS模式下的通信服務。
SMTP:郵件傳送協議,用於發送郵件。服務器開放的是25號端口。
POP3:它是和SMTP對應,POP3用於接收郵件。POP3協議所用的是110端口。
HTTP:是從Web服務器傳輸超文本到本地瀏覽器的傳送協議,端口默認80。
UDP對應的協議:
DNS:用於域名解析服務,將域名地址轉換為IP地址。DNS用的是53號端口。
SNMP:簡單網絡管理協議,使用161號端口,是用來管理網絡設備的。由於網絡設備很多,無連接的服務就體現出其優勢。
TFTP(Trival File TransferProtocal),簡單文件傳輸協議,該協議在熟知端口69上使用UDP服務。
6、TCP數據包結構
表6-1 控制位 | |
控制位 | 說明 |
URG | 為 1 表示緊急指針有效,為 0 則忽略緊急指針值。 |
ACK | 為 1 表示確認號有效,為 0 表示報文中不包含確認信息,忽略確認號字段。 |
PSH | 為 1 表示是帶有 PUSH 標志的數據,指示接收方應該盡快將這個報文段交給應用層而不用等待緩沖區裝滿。 |
RST | 用於復位由於主機崩潰或其他原因而出現錯誤的連接。它還可以用於拒絕非法的報文段和拒絕連接請求。 一般情況下,如果收到一個 RST 為 1 的報文,那么一定發生了某些問題。 |
SYN | 同步序號,為 1 表示連接請求,用於建立連接和使順序號同步( synchronize ) |
FIN | 用於釋放連接,為 1 表示發送方已經沒有數據發送了,即關閉本方數據流 |
源端口:16比特,用於表示應用層的連接。表示產生數據包的應用層進程
目的端口:16比特,用於表示應用層的連接。表示數據包所要到達的目的進程。
序列號 seq:32比特,表示數據流中的字節數。序列號為首字節在整個數據流中的位置。初始序列號隨機產生,並在連接建立階段予以同步。
確認號 ack:32比特,表示確認號為序列號加上1的數據包及其以前的所有數據包已經正確接收,也就是說他相當於下一個准備接收的字節的序列號。
頭部信息:4比特,用於指示數據起始位置。由於TCP包頭中可選項的長度可變,因此整個包頭的長度不固定。如果沒有附加字段,則TCP數據包基本長度為20字節。
窗口:16位,表示源端主機在請求接收端等待確認之前需要接收的字節數。它用於流量控制,窗口大小根據網絡擁塞情況和資源可用性進行增減。
校驗位:16位。用於檢查TCP數據包頭和數據的一致性。
緊急指針:16位。當URG碼有效時只向緊急數據字節。
可選項:存在時表示TCP包頭后還有另外的4字節數據。TCP常用的選項為最大數據包(並非整個TCP報文)MSS。每一個TCP段都包含一個固定的20字節的段頭。TCP段頭由20字節固定頭和一些可選項組成。實際數據部分最多可以有65495(65535-20-20=65495)字節。
7.1、TCP三次握手的全過程
第一次握手:客戶端發送syn包(syn=x)到服務器,並進入SYN_SEND狀態,等待服務器確認;
第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=x+1),同時自己也發送一個SYN包(syn=y),即SYN+ACK包,此時服務器進入SYN_RECV狀態;
第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=y+1),此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手。
注:握手過程中傳送的包里不包含數據,三次握手完畢后,客戶端與服務器才正式開始傳送數據。理想狀態下,TCP連接一旦建立,在通信雙方中的任何一方主動關閉連接之前,TCP 連接都將被一直保持下去。
7.2、為什么要三次握手
三次握手的目的是建立可靠的通信信道,說到通訊,簡單來說就是數據的發送與接收,而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。
第一次握手:Client 什么都不能確認;Server 確認了對方發送正常
第二次握手:Client 確認了:自己發送、接收正常,對方發送、接收正常;Server 確認了:自己接收正常,對方發送正常
第三次握手:Client 確認了:自己發送、接收正常,對方發送、接收正常;Server 確認了:自己發送、接收正常,對方發送接收正常
所以三次握手就能確認雙發收發功能都正常,缺一不可。
8、TCP的四次揮手全過程
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連接的時間要比客戶端早一些。
9、HTTP傳輸流程
HTTP 是一種無狀態協議 . 無狀態是指客戶端和服務端之間不需要建立持久的連接 , 客戶端發起一個請求 , 服務器端返回響應 , 這個連接就會被關閉 , 在服務器端不會保留該請求的有關信息 .
HTTP的工作流程如下 :
1.地址解析:地址解析是通過域名系統DNS解析服務器域名從而獲得主機的IP地址。
2.封裝HTTP 請求:解析協議名、主機名、端口、對象路徑等並結合本機的一些信息封裝成一個 HTTP 請求數據包。
3.封裝 TCP 包:將HTTP請求數據包進一步封裝成TCP數據包。
4.建立TCP連接:基於TCP三次握手機制建立TCP連接。
5.客戶端發送請求命令:在連接建立之后 , 客戶端發送 HTTP 請求到服務端與請求相關的信息都會包含在請求頭和請求體中發送給服務器端
6.服務器端響應:服務器在接收到請求后,結合業務邏輯進行數據處理,然后向客戶端返回相應的響應信息。響應信息包括:狀態行、協議版本號、成功或錯誤代碼和消息體等內容。
7.關閉連接:服務器端在發送完響應之后 , 就會關閉連接 , 如果客戶端的請求的頭部信息中有 Connection:keep-alive , 那么客戶端在響應完這個請求之后不會關閉連接 , 知道客戶端的所有請求都響應完畢 , 才會關閉連接 , 這樣大大節省了帶寬和 IO 資源 .
10、HTTPS
HTTPS協議 = HTTP協議 + SSL/TLS協議,在HTTPS數據傳輸的過程中,需要用SSL/TLS對數據進行加密和解密,需要用HTTP對加密后的數據進行傳輸。
SSL的全稱是Secure Sockets Layer,即安全套接層協議,是為網絡通信提供安全及數據完整性的一種安全協議。
TLS的全稱是Transport Layer Security,即安全傳輸層協議。雖然TLS與SSL3.0在加密算法上不同,但是在我們理解HTTPS的過程中,我們可以把SSL和TLS看做是同一個協議。
HTTPS為了兼顧安全與效率,同時使用了對稱加密和非對稱加密。數據是被對稱加密傳輸的,對稱加密過程需要客戶端的一個密鑰,為了確保能把該密鑰安全傳輸到服務器端,采用非對稱加密對該密鑰進行加密傳輸,總的來說,對數據進行對稱加密,對稱加密所要使用的密鑰通過非對稱加密傳輸。
11、HTTPS傳輸過程
1.客戶端向服務器發起HTTPS請求,連接到服務器的443端口
2.服務器端有一個密鑰對,即公鑰和私鑰,是用來進行非對稱加密使用的,服務器端保存着私鑰,不能將其泄露,公鑰可以發送給任何人。
3.服務器將自己的公鑰發送給客戶端。
4.客戶端收到服務器端的公鑰之后,會對公鑰進行檢查,驗證其合法性,如果發現發現公鑰有問題,那么HTTPS傳輸就無法繼續。嚴格的說,這里應該是驗證服務器發送的數字證書的合法性,關於客戶端如何驗證數字證書的合法性,下文會進行說明。如果公鑰合格,那么客戶端會生成一個隨機值,這個隨機值就是用於進行對稱加密的密鑰,我們將該密鑰稱之為client key,即客戶端密鑰,這樣在概念上和服務器端的密鑰容易進行區分。然后用服務器的公鑰對客戶端密鑰進行非對稱加密,這樣客戶端密鑰就變成密文了,至此,HTTPS中的第一次HTTP請求結束。
5.客戶端會發起HTTPS中的第二個HTTP請求,將加密之后的客戶端密鑰發送給服務器。
6.服務器接收到客戶端發來的密文之后,會用自己的私鑰對其進行非對稱解密,解密之后的明文就是客戶端密鑰,然后用客戶端密鑰對數據進行對稱加密,這樣數據就變成了密文。
7.然后服務器將加密后的密文發送給客戶端。
8.客戶端收到服務器發送來的密文,用客戶端密鑰對其進行對稱解密,得到服務器發送的數據。這樣HTTPS中的第二個HTTP請求結束,整個HTTPS傳輸完成。
12、TCP協議如何保證傳輸的可靠性
(1)應用數據被分割成 TCP 認為最適合發送的數據塊。
(2)TCP 給發送的每一個包進行編號,接收方對數據包進行排序,把有序數據傳送給應用層。
(3)校驗和: TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和,目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯,TCP 將丟棄這個報文段和不確認收到此報文段。
(4)TCP 的接收端會丟棄重復的數據。
(5)流量控制: TCP 連接的每一方都有固定大小的緩沖空間,TCP的接收端只允許發送端發送接收端緩沖區能接納的數據。當接收方來不及處理發送方的數據,能提示發送方降低發送的速率,防止包丟失。TCP 使用的流量控制協議是可變大小的滑動窗口協議。 (TCP 利用滑動窗口實現流量控制)
(6)擁塞控制: 當網絡擁塞時,減少數據的發送。如果有發生丟包則通過擁塞控制減小窗口,確定出合適(慢啟動 擁塞避免 快重傳 快恢復)的擁塞窗口。
①慢啟動:不要一開始就發送大量的數據,先探測一下網絡的擁塞程度,也就是說由小到大逐漸增加擁塞窗口的大小;
②擁塞避免:擁塞避免算法讓擁塞窗口緩慢增長,即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1,而不是加倍,這樣擁塞窗口按線性規律緩慢增長。
③快重傳:快重傳要求接收方在收到一個 失序的報文段 后就立即發出 重復確認(為的是使發送方及早知道有報文段沒有到達對方)而不要等到自己發送數據時捎帶確認。快重傳算法規定,發送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段,而不必繼續等待設置的重傳計時器時間到期。
④快恢復:快重傳配合使用的還有快恢復算法,當發送方連續收到三個重復確認時,就執行“乘法減小”算法,把ssthresh門限減半,但是接下去並不執行慢開始算法:因為如果網絡出現擁塞的話就不會收到好幾個重復的確認,所以發送方現在認為網絡可能沒有出現擁塞。所以此時不執行慢開始算法,而是將cwnd設置為ssthresh的大小,然后執行擁塞避免算法。
(7)停止等待協議 也是為了實現可靠傳輸的,它的基本原理就是每發完一個分組就停止發送,等待對方確認。在收到確認后再發下一個分組。 超時重傳: 當 TCP 發出一個段后,它啟動一個定時器,等待目的端確認收到這個報文段。如果不能及時收到一個確認,將重發這個報文段。
13、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查詢失敗。
14、DNS(Domain Name System 域名系統),簡單描述其工作原理。
當DNS客戶機需要在程序中使用名稱時,它會查詢DNS服務器來解析該名稱。 客戶機發送的每條查詢信息包括三條信息:包括:指定的DNS域名,指定的查詢類型,DNS域名的指定類別。 基於UDP服務,端口53. 該應用一般不直接為用戶使用,而是為其他應用服務,如HTTP,SMTP等在其中需要完成主機名到IP地址的轉換。
15、HTTP中常見狀態碼
狀態碼 |
原因短語 |
消息響應(1XX) |
|
100 |
Continue(繼續) |
101 |
Switching Protocol(切換協議) |
成功響應(2XX) |
|
200 |
成功 |
201 |
已創建 |
202 |
已接受 |
203 |
未授權信息 |
204 |
無內容 |
205 |
重置內容 |
206 |
部分內容 |
網絡重定向(3XX) |
|
300 |
多重選擇 |
301 |
永久移動 |
302 |
臨時移動 |
303 |
查看其它位置 |
304 |
未修改 |
305 |
使用代理 |
306 |
未使用 |
307 |
臨時重定向 |
308 |
永久重定向 |
客戶端錯誤(4XX) |
|
400 |
錯誤請求 |
401 |
未授權 |
402 |
需要付款 |
403 |
禁止訪問 |
404 |
未找到 |
405 |
不允許使用該方法 |
406 |
無法接收 |
407 |
要求代理身份驗證 |
408 |
請求超時 |
409 |
沖突 |
410 |
已失效 |
411 |
需要內容的長度 |
412 |
預處理失敗 |
413 |
請求實體過長 |
414 |
請求網址過長 |
415 |
媒體類型不支持 |
416 |
請求范圍不合要求 |
417 |
預期結果失敗 |
服務器端錯誤(5XX) |
|
500 |
內部服務器錯誤 |
501 |
未實現 |
502 |
網關錯誤 |
503 |
服務不可用 |
504 |
網管超時 |
505 |
HTTP版本不受支持 |