前言: 搞java開發的時候突然對網絡產生了興趣,兜兜轉轉最終還是再次學習起了大二時候經常不聽課自學的網絡原理.
參考視頻是慕課網上的 一站式學習Java網絡編程 全面理解BIO/NIO/AIO 第二章 與 劍指Java面試-Offer直通車 第二章.
目錄
第一章 網絡基礎知識
1.1 七層網絡協議
當前市面上分別存在四層,五層,七層協議,而國際標準化組織iso制定的OSI七層協議模型是業界提出來的概念型框架,因此先來了解一下開放系統互連參考模型即OSI七層協議.
工程學科都是不斷迭代的,因此七層協議大概是這麼來的,
1.1.1 物理層
我們首先要解決兩臺物理機之間的通信需求,具體就是機器A向機器B發送比特流,機器B能收到這些比特流,這就是物理層要做的知識,物理層主要定義了物理設備的標準,如網線的類型,光纖的接口類型,各種傳輸介質的傳輸速率的,它的主要作用是傳輸比特流,即我們所謂的0101二進制數據將它們轉化爲電流強弱來進行傳輸,到達目的地後再轉爲0101的機器碼,也就是我們常說的數模轉換與模數轉換.
1.1.2 數據鏈路層
現在我們可以進行數據的傳輸了,但是數據傳輸的可能是錯的,不完整的,於是數據鏈路層應運而生,數據鏈路層定義瞭如何格式化數據以進行傳輸,以及如何控制對物理介質的訪問,通常還提供錯誤檢測與糾正.
本層將比特數據組成了幀,其中交換機工作在這一層,對幀解碼,並對幀中包含的信息把數據發送到正確的接收方.
1.1.3 網絡層
隨着網絡節點的不斷增加,點對點通信時是需要經過多個節點的,那麼如何選擇最佳路徑,變成了我們的首要需求,此時,便有了我們的網絡層.
它的主要功能是將網絡地址翻譯成物理地址並決定如何將數據從發送方路由到接收方,網絡層根據發送優先權,網絡擁塞程度,服務質量以及可選路由的花費來決定從一個網絡中節點A到另一個網絡中節點B的最佳路徑.
由於網絡層處理並智能指導數據傳送路由器並連接網絡各段,所以路由器屬於網絡層,此層的數據我們稱之爲數據包,此層我們需要關注的協議主要是TCP/IP協議裏的IP協議.
1.1.4 傳輸層
隨着網絡通信需求的進一步擴大,通信過程中需要發送大量的數據,如海量文件傳輸的可能需要很長時間,而網絡在通信的過程中,會中斷很多次,此時爲了保證傳輸大量文件時的準確性,需要對發送的數據進行切分,切割爲一個一個的段落,即segment進行發送.那麼其中一個段落丟失了該怎麼辦,要不要重傳,每個段落要按照順序到達嗎,這個便是傳輸層要考慮的問題了.
傳輸層解決了主機間的數據傳輸,數據傳輸可以是不同網絡的,並且傳輸層解決了傳輸質量的問題,該層稱之爲OSI模型中最重要的一層,傳輸協議同時機型流量控制,或是基於接收方可接收數據的快慢程度規定適當的發送速率.
除此之外傳輸層按照網絡能處理的最大尺寸,將較長的數據包進行強制分割,例如以太網無法接收大於1500字節的數據包,發送方節點的傳輸層將數據分割成較小的數據片,同時爲每個數據片安排一個序列號,以便數據到達接收方節點的傳輸層時能以正確的順序重組,該過程成爲排序.
傳輸層需要關注的協議有TCP/IP中的IP協議與UDP協議.
1.1.5 會話層
現在我們已經保證給正確的計算機發送爭取的封裝過後的信息了,但是用戶級別的體驗好不好?難道我們每次都要調用TCP去打包,然後調用IP協議去找路由,自己去發?當然不行,所以我們要建立一個自動收發包,自動尋址的功能,於是發明了會話層,會話層的作用就是建立和管理應用程序之間的通信.
1.1.6 表示層
現在我能保證應用程序自動收發包和尋址了,但我要用linux給windows發包,兩個系統語法不一致,就像exe不能在linux上運行一樣,shell在windows下也是不能直接執行的,於是需要表示層,幫我們解決不同系統之間通信語法的問題,在表示層數據將按照網絡能理解的方案進行格式化,這種格式化也因網絡使用的類型不同而不同,
1.1.7 應用層
此時雖然發送方知道自己發送的是什麼東西,轉換成字節數組之後有多長,但接收方肯定不知道,所以應用層的網絡協議誕生了,它規定發送方和接收方必須使用一個固定長度的消息頭,消息頭必須使用某種固定的組成,而且消息頭裏必須記錄消息體的長度等一系列信息,以方便接收方正確的解析發送方發送的數據,應用層旨在讓你更方便的應用從網絡中接收到的數據,至於數據的傳遞,沒有該層,也可以在兩臺電腦之間傳遞,只不過傳來傳去就是一堆1和0組成的字節數組.
該層需要我們重點關注的是與之相對應的TCP/IP協議中的HTTP協議.
1.2 數據的變化
從應用層開始,都會對要傳輸的數據頭部進行處理,加上本層的一些信息,最終由物理層通過以太網電纜等介質將數據解析成比特流,在網絡中傳輸,數據傳遞到目標地址,並自底而上將先前對應成的頭部解析分離出來.
1.3 TCP/IP
OSI是一個定義良好的協議規範集,並有許多可選部分完成類似的任務,它定義了開放系統的層次結構,層次之間的相互關係以及各層的可能的任務,是作爲一個框架來協調和組織各層所提供的服務,但是OSI參考模型並沒有提供一個實現的方法,而是描述了一些概念,用來協調進程間標準的制定.即OSI參考模型並不是一個標準,而是一個概念型框架.
事實的標準是TCP/IP四層架構參考模型,TCP/IP參考模型是首先由阿帕網所使用的體系結構,後來該結構被美國國防部用來做爲計算機網絡的標準,由於領頭大哥的推動,市面上絕大多數廠商也以該標準爲主用以商用,雖然TCP/IP協議並不完全符合OSI的七層參考模型,但我們依然可以理解爲其是OSI的一種實現.
從字面上講,有人可能以爲TCP/IP協議是TCP與IP這兩種協議,實際生活中有時確實就是指這兩種協議,然後在很多情況下,它只是利用IP進行通信時所必須用到的協議羣的統稱,具體來說,IP,ICMP,TCP,UDP,Telnet,FTP,Http等等都屬於TCP/IP協議,他們與TCP或ip的關係緊密,是互聯網必不可少的組成部分,TCP/IP一詞泛指這些協議,因此有時也稱TCP/IP爲網際協議羣.
從圖裏我們可以看出TCP/IP與OSI在分層協議上稍有區別,TCP/IP中的應用層可以理解爲約等於OSI中的應用層,表示層,會話層三層的組合,同時OSI的物理層和數據鏈路層在TCP/IP中被規定爲鏈路層,OSI模型注重通信協議必要的功能是什麼,而TCP/IP則更強調在計算機上實現協議應該開發哪種程序
下圖中可以看出,和OSI一樣,在數據的傳輸過程中,TCP/IP協議在傳輸過程中在每一層會對所發送的數據增加一個頭部,在這個首部中,包含了該層必要的信息如發送的目標地址,以及協議相關信息.
第二章 TCP簡介
我們都知道IP協議是無連接的通信協議,它不會佔用兩個正在通信的計算機之間的通信線路,這樣IP就降低了對網絡線路的需求,每條線可以滿足很多不同的計算機之間的通信需要,通過IP,消息或者其它數據會被分割爲較小的,獨立的包,並通過因特網在計算機之間傳送,IP負責將每個包路由至它的目的地,但IP沒有做任何事情確認包是否按順序發送,或者包是否被破壞,所以IP數據包是不可靠的,需要由它的上層協議來做出控制.
由TCP協議來進行控制,TCP簡介:
2.1 TCP報文頭部
源端口和目的端口各佔兩個字節,TCP和UDP都是不包含IP地址信息的,因爲那是IP層要做的事.我們可以用ip地址+協議+端口號唯一標識網絡中的一個進程,在一些場合也把這種唯一標識的模式稱爲套接字,也就是說雖然通信的重點是應用進程,但我們只要把應用的報文交到目的主機的某一個合適的端口,剩下的工作就由TCP來完成了.
swquence number是比較重要的序號,它佔用了四個字節,TCP連接中,傳送的字節流中的每個字節,都按順序去編號的,例如一段報文的序號字段值是107,而攜挾的數據共有100個字節,那麼如果有下一個報文段,其序號就應該從100+107-207開始.
再往下是ack確認號,同樣佔四個字節,期望收到對方下一個報文第一個數據字節的序號,例如B收到了A發來的報文,其序列號字段是301,而數據長度是200字節,那表明B正確收到了A發送的到序號301+200-1=500爲止的數據了.於是B期望收到A的下一個數據序號是501,於是B在發送給A的確認報文段中,會把ACK確認號置爲501.
接下來就是我們的offset,即數據偏移,由於頭部有可選字段,長度不固定,因此它指出TCP報文的數據距離TCP報文的起始距離有多遠.
reserved是保留域,目前都是0.
TCP Flags是控制位,主要有八個標誌位來組成,每個標誌位表示一個控制功能.
ACK爲1表示確認號有效,爲0表示報文中不含確認信息,忽略確認號字段.
SYN同步序列號,在連接請求中,SYN等於1與ack等於0表示該數據段沒有使用捎帶的確認域,而連接應答捎帶一個確認就是SYN等於1,ACK等於1.
FIN finish標誌,用於釋放連接,爲1時表示發送方已經沒有數據發送了.即要關閉數據流.
WINDOW窗口,即滑動窗口的大小,用來告知發送端接收端的緩存大小.以此控制發送端發送數據的速率.從而達到流量控制.
Checksum檢驗和,指的是奇偶校驗,此校驗和對整個的TCP報文段包括TCP頭部和TCP數據以16位進行計算所得,由發送端計算和存儲,由接收端進行驗證.
Urgent Poniter緊急指針,只有當URG爲1的時候纔有效,指出本報文段中緊急數據的字節數.
TCP Options可選項,長度可變,定義一些其它的可選參數.
2.2 三次握手
當應用程序希望通過TCP與另一個應用進行通信時,它會發一個通信請求,這個請求必須送到一個確切的地址,在雙方握手之後,TCP將在兩個應用之間建立一個全雙工的通信,這個全雙工的通信將佔用兩個計算機之間的通信線路,直到它被一方或雙方關閉爲止.
距離流程如下,圖應該能看懂,網上也很多
爲什麼需要三次握手才能建立起連接?
主要是爲了初始化Sequence Number的初始值,通信的雙方要互相通知對方自己的初始化的Sequence Number.也就是上面的x和y,這兩個要作爲以後通訊的序號.以保證應用層接收到的數據不會因爲網絡上的傳輸問題而亂序,即TCP會用這個序號來拼接數據.因此在服務器回發它的Sequence Number即第二次握手之後,還需要發送確認報文給服務器告知服務器說客戶端已經收到了你的初始化Sequence Number了.
2.3 四次揮手
四次揮手指的是終止TCP連接時,需要客戶端和服務端總共發出四個包,以確認連接的斷開.在socket編程中,這個過程由客戶端和服務端任意一方執行close來觸發.這裏我們假設由客戶端來主動觸發close.四次揮手流程如下圖所示
客戶端發出的停止連接報文的序列號u,u表示前面establish狀態下已經傳送過來的數據的最後一個字節的序號加1.
小知識:
1.注意到四次揮手的過程中,從TIME-WAIT狀態到CLOSED狀態有一個超時設置,這個超時設置是2*MSL,那爲什麼需要等待這一段時間,不直接轉換成close狀態?
2.爲什麼需要四次揮手才能斷開連接?
因爲連接是全雙工的,即數據可以在兩個方向上進行傳輸,所以雙方都需要FIN報文和ACK報文,所以發送與接收方各需要兩揮手即可,只不過有一方是被動的,所以看上去就成了所謂的四次揮手.
3.服務器出現大量CLOSE_WAIT狀態的原因
問題的其中一個表現是客戶端一直在請求,但是返回給客戶端的信息是異常的,服務端也壓根沒收到請求.
看上圖只有一個原因,即收到對方的關閉請求後一直沒有發送確認ACK報文.即
所以我們要:
4. 瀏覽器和服務器關閉TCP連接時間
根據Connection請求頭，如果是keep-alive服務器就保持住tcp連接，如果沒有或是close則服務器response傳輸完後主動關閉tcp連接。當然現在瀏覽器都是http1.1都默認是keep-alive的，在瀏覽器tab關閉時，tcp連接關閉。
5. 爲什麼握手是三次而揮手是四次?
這個是自己推斷的,因爲握手時,接收方接收到請求可以立即回覆無影響,但是揮手時,接收方立即回覆後還可能回發數據,所以要發第二次表明自己發送完了,發送方可以關了,那接收方收到斷開連接請求時,不能不直接發送,等要發給接收方發完數據然後回覆你可以關了,這樣不就一次了,這樣不行是因爲發送方沒收到確認收到消息會一直髮送.
2.4 TCP與UDP的區別
2.4.1 TCP簡介
UDP頭:
2.4.2 區別
UDP 適用於在線媒體,多人廣播,在線遊戲
第三章 HTTP
3.1 簡介
這個平時經常用很熟悉了,網上資料也很多,簡要描述一下.
HTTP特點:
支持客戶/服務器模式
簡單快速.客戶端向服務器請求服務的時候,只需要傳送請求方法和路徑,請求方法常用的有GET,HEAD,POST,每種方法規定了與服務器聯繫的類型不同,由於http協議簡單,使得http程序的規模小,因而通信速度很快.
靈活.允許傳輸任意類型的對象,類型由content-type加以標記.
無連接.限制每次連接只處理一個請求,服務器處理完客戶的請求,並收到客戶的應答後即斷開連接,採用這種方式可以節省傳輸時間.
從http1.1起默認使用了長連接,服務器需要等待一定時間後才斷開連接,以保證連接效率.
無狀態.意味着後續處理需要前段信息則必須被重傳,這樣可能導致每次傳輸的數據量增大.在服務器不需要先前應答時,它的速度就較快.
get請求與post請求的區別:
Cookie與Session的區別:
3.2 DNS解析過程
我們的域名其實是省略了root,比如如下,從右向左分別代表了不同層級,解析也是從右向左解析的.分層相當於爲全網絡的域名做了一個類似於索引的工作,當我們需要查找某一個特定的域名的時候,我們可以根據層級,以層層遞進的方式找到我們需要的域名.
域名查找的兩種方式:遞歸與迭代
遞歸查找:
根域名服務器找得到地址就把地址返回給DNS服務器,如果找不到根域名服務器就會去頂級域名找以此類推找到最後面的三級域名服務器,如果找到了就會一個個服務器返回.
迭代查詢:
根域名找不到,把頂級域名的地址告訴DNS客戶端,讓DNS客戶端去找,如果頂級域名服務器找不到地址,再重複上述的過程,直到找到域名的具體地址,由服務器返回給DNS客戶端,再返回給瀏覽器.
3.3 HTTP和HTTPS的區別
在之前我們對網絡數據的抓包中發現,用戶的信息都裸奔在互聯網上,容易被抓包然後暴露信息,或者僞造回覆而不被客戶端察覺(所謂的劫持).
要給數據裹上一層外套,人們便想到了加密.
非對稱加密稱加密用公鑰進行加密,私鑰進行解密.
常用的哈希算法有MD5等等.
數字簽名就是在信息的後面加上一段內容,這些內容是經過哈希後的值,可以證明信息沒有被修改過,哈希值一般都會加密後,也就是簽名後,再和信息一起發送.以保證哈希值不被修改.
在使用的過程中人們發現,僅使用其中的某種加密方式並不能滿足生產要求,要麼非對稱加密性能過低,要麼對稱密鑰容易泄漏,因此https使用的是證書配合各種加密手段的方式.
HTTPS數據傳輸流程:HTTPS在進行傳輸之前,會與網站服務器和web瀏覽器進行一次握手,在握手時確定雙方的加密密碼信息.具體過程如下:
瀏覽器將支持的加密信息發送給服務器,如本地僅支持AES對稱加密,ECC非對稱加密.
服務器會依據瀏覽器提供的這一套支持的加密算法,在自己所提供的加密方式中,選出一套哈希算法和加密算法,將驗證身份的信息以證書的形式發送回瀏覽器.證書的信息包含了發佈證書的CA機構,證書的有效期,公鑰,證書所有者,簽名等等.CA機構是具備證書發佈資格的權威機構,好比英語四六級委員會.
瀏覽器驗證證書合法性,如果驗證證書的有效性,則在瀏覽器地址欄會有標誌顯示,否則會顯示不受信的標識.當證書受信後,web瀏覽器會隨機生成一份密碼,並使用證書中的公鑰加密爲A,之後就是使用約定好的哈希算法加密握手消息,生成B,並用剛纔的密碼對稱加密B生成C,最後將它們回發給服務器.
服務器接收到瀏覽器發來的信息後,會使用網站本身的私鑰將A解密得到隨機生成的密碼,通過密碼解密瀏覽器發送過來的C,並驗證解密後的值與B是否相等,如果相等,然後服務器會將經過哈希的握手信息D與加密後的D即E發送給瀏覽器.
客戶端瀏覽器解密響應消息,並解密消息E,如果與服務器發送過來的D一致,則此握手過程結束後,服務器和瀏覽器會使用之前瀏覽器生成的隨機密碼和對稱加密算法進行加密和交換數據.
注:握手信息就是三次握手的信息,要哈希主要是確保消息在傳輸過程中不被更改.
HTTP與HTTPS的區別:
第四章 socket
ip層的ip地址可以唯一標識一臺主機,TCP協議和端口可以唯一標識主機的一個進程.所以我們可以用ip地址+TCP協議+端口唯一標識網絡中的一個進程.能夠標識進程後就可以用socket進行通信了.
socket是對TCP/IP協議的抽象,是操作系統對外開放的接口.
socket起源於unix,而unix是遵從一切皆文件的哲學,socket是基於一種從打開到讀和寫再到關閉的模式去實現的,服務器和客戶端各自維護一個文件,在建立連接打開後,可以向自己文件寫入內容,供對方讀取或者讀取對方內容,在通訊結束時,會關閉文件.
個人理解:socket封裝TCP/UDP的一些操作,所以可以用socket提供的api實現互聯、傳輸數據等等.
具體API操作的流程:
