java面試--計算機網路

 計算機網路體系結構

 計算機網路五層體系結構

1、應用層

應用層的任務是通過應用程式之間的互動來完成特定網路應用。應用層協議定義的是應用程式之間的通訊與互動規則。對於不同的網路應用需要不同的用用層協議。比如DNS(域名系統),HTTP協議，支援電子郵件的SMTP協議等等。應用層互動的資料單元為報文。

1. 域名系統：作為可以將域名和IP地址相互對映的一個分散式資料庫，能夠使人更方便的訪問網際網路不必記住IP地址。
2. HTTP協議(超文字傳輸協議)：所有的www檔案都得遵循HTTP協議，涉及HTTP是為了提供一種帆布和接收HTML頁面的方法
3. SMTP協議：

2、傳輸層

傳輸層的主要任務就是負責向兩臺主機的程式之間的通訊提供通用的資料傳輸服務。應用程式利用該服務傳輸應用層報文，“通用的”是指並不針對某一個特定的網路應用，而是多種應用可以使用同一個運輸層服務。傳輸層具有複用(多個應用層程式同時使用傳輸層服務)與分用(傳輸層將相應的資料包分別交付到相應的程式)的功能。在傳輸層中主要有兩種協議UDP與TCP協議

1. UDP:UDP是無連線的；UDP盡最大努力互動但是不保證可靠交付；UDP是面向報文的；UDP沒有擁塞控制，因此出現網路擁擠的時候，也不會降低源主機的放傳送速率(實時視訊會議，IP電話)；UDP支援一對一，一對多，多對一，多對多；UDP的首部開銷小，只有8個位元組。TCP首部為20~60個位元組不等。
2. TCP：TCP是面向連線的；TCP提供可靠交付，通過TCP傳輸的資料無差錯，不丟失，不重複，有序；每一個TCP連線只能有兩個端點，是一對一的；TCP是面向位元組流的；TCP提供全雙工通訊，TCP允許通訊的雙方的應用程式在任何時候都可以接收或傳送資料。TCP連線的兩端都設有傳送快取和接收快取，用來臨時存放雙方通訊的資料；

3、網路層

網路層的任務為實現兩個主機系統之間的資料透明傳輸，其實現了同一個子網的其具體功能有路由，路由選擇，邏輯定址。IP協議非常簡單，僅僅提供不可靠、無連線的傳送服務。IP協議的主要功能有：無連線資料包傳輸、資料包路由選擇和差錯控制。與IP協議配套使用實現其功能的還有地址解析協議ARP、逆地址解析協議RARP、ICMP(因特網控制報文協議)，IGMP(因特網組管理協議)

網路層中，不僅負責對子網之間的資料包進行路由選擇，另外，網路層還可以擁塞控制，國際互連等功能；其基本資料單位為IP資料包；其重要的裝置為路由器。

4、資料鏈路層

資料鏈路層最基本的服務為將源自網路層的資料可靠的傳輸到相鄰節點的網路層。在兩個相鄰節點之間傳送資料時，資料鏈路層將網路層交下來的IP資料包組裝程幀，在兩個相鄰節點間的鏈路上傳送幀。每一幀包括資料和必要的控制資訊（如同步資訊，地址資訊，差錯控制等）。該層的作用包括：實體地址定址、資料的成幀、流量控制、資料的檢錯、重發等。資料的基本單位是幀。主要的協議為乙太網協議。主要的裝置為網橋和交換機

5、物理層

 物理層(physical layer)的作用是實現相鄰計算機節點之間位元流的透明傳送，儘可能遮蔽掉具體傳輸介質和物理裝置的差異。其主要裝置為集線器與中繼器

每一層的協議如下：

物理層：RJ45、CLOCK、IEEE802.3    （中繼器，集線器，閘道器）

資料鏈路：PPP、FR、HDLC、VLAN、MAC  （網橋，交換機）

網路層：IP、ICMP、ARP(地址解析協議)、RARP(逆向地址解析協議)、OSPF(開放最短路徑協議)、IPX、RIP、IGRP、 （路由器）

傳輸層：TCP、UDP、SPX

會話層：NFS、SQL、NETBIOS、RPC

表示層：JPEG、MPEG、ASCII

應用層：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS、DHCP

其中，基於TCP的有：
Telnet(Teletype over the Network, 網路電傳) ，通過一個終端(terminal)登陸到網路。FTP(File Transfer Protocol, 檔案傳輸協議) ，由名知義。SMTP(Simple Mail Transfer Protocol，簡單郵件傳輸協議) ，用來傳送電子郵件。POP3(Post Office Protocol 3)郵件讀取協議，協議通常被用來接收電子郵件。HTTP。HTTPS

基於UDP的有：
NFS（網路檔案系統）。TFTP。SNMP(Simple Network Management Protocol, 簡單網路管理協議) ，用於網路資訊的收集和網路管理。DHCP。NTP(Network Time Protocol，網路時間協議) ，用於網路同步。BOOTP(Boot Protocol，啟動協議) ，應用於無盤裝置
基於UDP和TCP的有：
DNS(Domain Name Service，域名服務) ，用於完成地址查詢，郵件轉發等工作
ECHO(Echo Protocol, 迴繞協議) ，用於查錯及測量應答時間

 

 三次握手與四次揮手

1、三次握手

 為什麼要三次握手？為了建立可靠的通訊通道。

第一次握手：Client什麼都不能確認，Server確認了對方的傳送正常

第二次握手：Client確認了自己的傳送，接受正常，對方的傳送，接收正常；Server確認了自己接收正常，對方的傳送正常

第三次握手：Client 確認了：自己傳送、接收正常，對方傳送、接收正常；Server 確認了：自己傳送、接收正常，對方傳送接收正常

為什麼傳回syn? 

為了告訴傳送端，我接收到的資訊確實是你傳送的訊號 

傳了 SYN,為啥還要傳 ACK？

傳了 SYN，證明傳送方到接收方的通道沒有問題，但是接收方到傳送方的通道還需要 ACK 訊號來進行驗證。

四次揮手

1.  客戶端傳送一個FIN，用來關閉客戶端到伺服器的資料傳送
2. 伺服器收到FIN，發揮一個ACK，確認序號為收到的序號加1
3. 伺服器關閉與客戶端之間的連結，傳送一個FIN
4. 客戶端返回ACK報文確認，並將確認序列號設定為收到的序列號+1

為什麼要四次揮手？

任何一方都可以在資料傳送結束後發出連線釋放的通知，待對方確認後進入半關閉狀態。當另一方也沒有資料再傳送的時候，則發出連線釋放通知，對方確認後就完全關閉了TCP連線。

為什麼是2倍的MSL?

• 原因一：保證TCP全雙工連線的可靠釋放

解析：假設場景為客戶端主動向伺服器發起斷開連線，假如在主動方（客戶端）最後一次傳送的ACK在網路中丟失，根據TCP的超時重傳機制，被動方（伺服器）需要重新向客戶端傳送FIN+ACK，在FIN未達到之前，必須維護這條連線；並且要接收到客戶端發出的ACK確認後才能終止連線；如果直接在重傳的FIN到達之前而關閉連線，當FIN到達後會促使客戶端TCP傳輸層傳送RST重新建立連線，而本質上這是一個正常斷開連線的過程。

• 原因二：為了使就得資料包在網路中因過期而失效

 解析：假設沒有time_wait狀態時，A剛剛與B斷開連線，C又以和A相同的ip和port和B建立起連線，TCP協議棧無法區分A和C是不同的連線， 這時，A連線傳送的資料到達B之後會被B的TCP傳輸層當做當下正常的連線發來的資料進行處理，實際上這時上一條連線的髒資料；所以在time_wait等待2MSL（報文在網路最大生存時間），將此連線的資料全部收到並丟棄，才能保證這些資料不會造成錯誤；

TCP如何保證可靠傳輸？

• 應用資料被分割成TCP認為最適合傳送的資料塊。

• 超時重傳： 當TCP發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。

• TCP給傳送的每一個包進行編號，接收方對資料包進行排序，把有序資料傳送給應用層。

• 校驗和： TCP將保持它首部和資料的檢驗和。這是一個端到端的檢驗和，目的是檢測資料在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段。

• TCP的接收端會丟棄重複的資料。

• 流量控制： TCP連線的每一方都有固定大小的緩衝空間，TCP的接收端只允許傳送端傳送接收端緩衝區能接納的我資料。當接收方來不及處理髮送方的資料，能提示傳送方降低傳送的速率，防止包丟失。TCP使用的流量控制協議是可變大小的滑動視窗協議。 （TCP利用滑動視窗實現流量控制）

• 擁塞控制： 當網路擁塞時，減少資料的傳送。①視窗機制：通過調節視窗的大小實現對傳送資料速率的調整。②視窗調整的基本策略：AIMD（Additive Increase,Multiplicative Decrease）加性增加，乘性減少；網路未發生擁塞時，逐漸“加性”增加視窗大小，當網路擁塞時“乘性”快速減小視窗大小。③TCP的擁塞控制演算法：包括了慢啟動、擁塞避免、快速重傳和快速恢復4部分。

• 停止等待ARQ協議（stop and wait） 也是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止傳送，等待對方確認。在收到確認後再發下一個分組
   

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

 

 

各種協議與HTTP協議之間的關係

 

 HTTP長連線、短連線

在HTTP1.0中，預設使用的是短連線，即客戶端與伺服器每進行一次HTTP請求，就會建議一次連結。任務結束連結就中斷。當客戶端瀏覽器訪問的某個HTML或其他型別的Web頁中包含有其他的Web資源（如JavaScript檔案、影像檔案、CSS檔案等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。

在使用長連線的情況下，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸HTTP資料的TCP連線不會關閉，客戶端再次訪問這個伺服器時，會繼續使用這一條已經建立的連線。Keep-Alive不會永久保持連線，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。實現長連線需要客戶端和服務端都支援長連線。

從HTTP1.1起，預設使用長連線，會在響應頭加入如下程式碼：

Connection:keep-alive

 Http1.0,Http1.1,Http2.0

點選檢視詳情

 HTTP與HTTPS的區別

Http協議執行在TCP之上，明文傳輸，客戶端與伺服器端都無法驗證對方的身份；
Https是身披SSL(Secure Socket Layer)外殼的Http，執行於SSL上，SSL執行於TCP之上，是新增了加密和認證機制的HTTP。Https的加密機制是一種共享祕鑰加密和公開祕鑰加密並用的混合加密機制
二者存在以下不同：

• 埠不同：Http與Http使用不同的連線方式，用的埠也不一樣，前者是80，後者是443；
• 資源消耗：和HTTP通訊相比，Https通訊會由於加減密處理消耗更多的CPU和記憶體資源；
• 開銷：Https通訊需要證照，而證照一般需要向認證機構購買；

HTTP中Cookie和Session的作用和區別？

HTTP協議是一種無狀態協議，在資料交換完畢後，服務端和客戶端的連結就會關閉，每次交換資料都需要建立新的連結。此時，伺服器無法從連結上跟蹤會話。cookie和session可以跟蹤會話，彌補HTTP無狀態協議的不足。session機制採用的是在服務端保持狀態的方案，而cookie機制則是在客戶端保持狀態的方案

cookie原理：

• 伺服器建立cookie物件，把會話資料儲存到cookie物件中；

• 伺服器傳送cookie資訊到瀏覽器；

• 瀏覽器得到伺服器傳送的cookie，然後儲存在瀏覽器端；

• 瀏覽器在下次訪問伺服器時，會帶著cookie資訊；

• 伺服器接收到瀏覽器帶來的cookie資訊。

Session原理：

• 第一次訪問建立session物件，給session物件分配一個唯一的ID，叫JSESSIONID；

• 把JSESSIONID作為Cookie的值傳送給瀏覽器儲存；

• 第二次訪問的時候，瀏覽器帶著JSESSIONID的cookie訪問伺服器；

• 伺服器得到JSESSIONID，在伺服器的記憶體中搜尋是否存放對應編號的session物件；

• 如果找到對應編號的session物件，直接返回該物件；

• 如果找不到對應編號的session物件，建立新的session物件。

 

 

於2020/10/10完成

參考連結：

https://www.imooc.com/article/286193

https://www.imooc.com/article/309775

https://www.imooc.com/article/68603

https://www.imooc.com/article/48819

 

 

狀態碼