-
C/S結構與B/S結構:
1、C/S(Client/Server)結構:適用于個人娛樂市場【QQ等】
(1)、優點:安全性高、且有效降低服務器壓力;
(2)、不足:增加服務成本、更新較繁瑣;

2、B/S(Browser/Server)結構:適用于個人或企業
(1)、優點:不會增加用戶獲取服務的成本、且無需更新瀏覽器;
(2)、不足:無法有效對資源檔案進行保護、服務器壓力大(多執行緒、高并發問題);

-
ISO/OSI參考模型、TCP/IP參考模型、5層參考模型:
計算機網路是一個將分散且具備獨立功能的計算機系統,通過通信設備與線路連接起來,由功能完善的軟體實作資源共享和資訊傳遞的系統;


-
各種協議(了解):
1、ICMP協議:因特網控制報文協議,它是TCP/IP協議族的一個子協議,用于在IP主機、路由器之間傳遞控制訊息,
2、TFTP協議:是TCP/IP協議族中的一個用來在客戶機與服務器之間進行簡單檔案傳輸的協議,提供不復雜、開銷不大的檔案傳輸服務,
3、HTTP協議:超文本傳輸協議,是一個屬于應用層的面向物件的協議,由于其簡捷、快速的方式,適用于分布式超媒體資訊系統,
4、DHCP協議:動態主機配置協議,是一種讓系統得以連接到網路上,并獲取所需要的配置引數手段,
5、NAT協議:網路地址轉換屬接入廣域網(WAN)技術,是一種將私有(保留)地址轉化為合法IP地址的轉換技術,
6、DHCP協議:一個局域網的網路協議,使用UDP協議作業,用于給內部網路或網路服務供應商自動分配IP地址,給用戶或者內部網路管理員作為對所有計算機作中央管理的手段,
-
TCP協議和UDP協議的區別(傳輸層):
1、TCP協議是有連接的,有連接的意思是開始傳輸實際資料之前TCP的客戶端和服務器端必須通過三次握手建立連接,會話結束之后也要結束連接,而UDP是無連接的,
2、TCP協議保證資料按序發送,按序到達,提供超時重傳來保證可靠性,但是UDP不保證按序到達,甚至不保證到達,只是努力交付,即便是按序發送的序列,也不保證按序送到,
3、TCP協議所需資源多,TCP首部需20個位元組(不算可選項),UDP首部欄位只需8個位元組,
4、TCP有流量控制和擁塞控制,UDP沒有,網路擁堵不會影響發送端的發送速率
5、TCP是一對一的連接,而UDP則可以支持一對一,多對多,一對多的通信,
6、TCP面向的是位元組流的服務,UDP面向的是報文的服務,
-
TCP/IP的三次握手:
TCP握手協議:TCP/IP協議中,TCP協議提供可靠的連接服務,采用三次握手建立一個連接,
1、第一次握手:建立連接時,客戶端發送SYN包(SYN=1,seq=x(隨機))到服務器,并進入SYN_SEND狀態,等待服務器確認; SYN:同步序列編號(Synchronize Sequence Numbers)
2、第二次握手:服務器收到SYN包,必須確認客戶的SYN(ack=x+1),同時自己也發送一個SYN包(seq =k),即SYN+ACK包,此時服務器進入SYN_RECV狀態;
3、第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手,
完成三次握手,客戶端與服務器開始傳送資料,

-
TCP/IP四次揮手:
1、客戶端打算關閉連接,此時會發送一個TCP首部 FIN 標志位被置為 1 的報文,也即 FIN 報文,之后客戶端進入 FIN_WAIT_1 狀態,
2、服務端收到該報文后,就向客戶端發送 ACK 應答報文,接著服務端進入 CLOSED_WAIT 狀態,
3、客戶端收到服務端的 ACK 應答報文后,之后進入 FIN_WAIT_2 狀態,
4、等待服務端處理完資料后,也向客戶端發送 FIN 報文,之后服務端進入 LAST_ACK 狀態,5、客戶端收到服務端的 FIN 報文后,回一個 ACK 應答報文,之后進入 TIME_WAIT 狀態
6、服務器收到了 ACK 應答報文后,就進入了 CLOSE 狀態,至此服務端已經完成連接的關閉,
7、客戶端在經過 2MSL 一段時間后,自動進入 CLOSE 狀態,至此客戶端也完成連接的關閉,
每個方向都需要一個 FIN 和一個 ACK,因此通常被稱為四次揮手,
注:主動關閉連接的,才有TIME_WAIT狀態,

-
TCP/IP四次揮手釋放連接時,TIME_WAIT等待2MSL的意義:
1、MSL :報文最大生存時間,它是任何報文在網路上存在的最長時間,超過這個時間報文將被丟棄,
2、TIME_WAIT等待2倍的MSL,比較合理的解釋是:網路中可能存在來自發送方的資料包,當這些發送方的資料包被接收方處理后又會向對方發送回應,所以一來一回需要等待2倍的時間,
-
為什么TCP/IP是三次握手?不是兩次、四次?
1、TCP 連接:用于保證可靠性和流量控制維護的某些狀態資訊,這些資訊的組合,包括Socket、序列號和視窗大小稱為連接,
(1)、三次握手才可以阻止歷史重復連接的初始化(主要原因)
(2)、三次握手才可以同步雙方的初始序列號
(3)、三次握手才可以避免資源浪費
2、不使用「兩次握手」和「四次握手」的原因:
(1)、兩次握手:無法防止歷史連接的建立,會造成雙方資源的浪費,也無法可靠的同步雙方序列號;
(2)、四次握手:三次握手就已經理論上最少可靠連接建立,所以不需要使用更多的通信次數;
-
TCP粘包的產生:
1、發送端粘包:發送端需要等緩沖區滿才發送出去,造成粘包;
2、接收端粘包:接收端不及時接識訓沖區的包,造成多個包接收,
-
電腦上訪問一個網頁的整個流程(了解)
1、瀏覽器分析連接指向的頁面URL(http://www.baidu.com)
2、瀏覽器向DNS請求www.baidu.com.的IP地址
3、域名系統DNS決議出百度官網的服務器IP地址
4、瀏覽器與該服務器建立TCP連接(默認埠80)
5、瀏覽器發出HTTP請求獲取指定頁面,
6、服務器通過HTTP回應把檔案對應頁面發送給瀏覽器,
7、TCP連接釋放,
8、瀏覽器將檔案進行決議,并將web網頁顯示給用戶
-
web服務器下共享資源檔案的分類:
1、靜態資源檔案(在瀏覽器下編譯執行):.html、.css、.js、.txt、.jpg
2、動態資源檔案(在服務器下編譯執行):.jsp、.class


-
瀏覽器發送請求的三要素:
1、發送請求地址:超鏈接<a>與表單域<form>標簽
2、發送請求方式:常用GET與POST方式
3、發送請求攜帶引數
-
Http請求協議包與Http回應協議包的內部結構(自上而下)
1、Http請求協議包:
(1)、請求行(保存請求地址與方式)
(2)、請求頭(GET請求引數資訊)
(3)、空白行
(4)、請求體(POST請求引數資訊)
2、Http回應協議包:
(1)、狀態行(Http狀態碼)
(2)、回應頭(編譯器)
(3)、空白行
(4)、回應體(靜態與動態資源檔案)

-
Http狀態碼(常見)
1xx:資訊性狀態碼
(100):收到了請求的起始部分,客戶端應該繼續請求
2xx:成功狀態碼
(200):服務器成功處理了請求
3xx:重定向狀態碼
(301):表示永久性重定向,被請求的資源的URL已永久移動到新位置,服務器回傳此回應時,會自動將請求者轉到新位置,
(302):表示臨時性重定向,請求的資源臨時從不同的URL回應請求,但請求者應繼續使用原有位置來進行以后的請求
4xx:客戶端錯誤狀態碼
(400):客戶端錯誤,表示提交請求引數程序中發送了一個錯誤的請求
(404):服務器未定位到訪問的資源檔案
(405):已定位到資源檔案,但瀏覽器采用的請求方式不能處理
5xx:服務器錯誤狀態碼
(500):Java例外導致處理失敗
-
HTTP和HTTPS的區別
1、https協議需要到ca申請證書,一般免費證書很少,需要交費
2、http是超文本傳輸協議,資訊是明文傳輸,https 則是具有安全性的ssl加密傳輸協議
3、http和https使用的是完全不同的連接方式用的埠也不一樣:前者是80,后者是443
4、http的連接很簡單,是無狀態的;HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸,身份認證的網路協議要比http協議安全
-
GET與POST請求方式的特點
1 、GET請求方式
(1)、發送請求時,請求攜帶引數的數量不能超過4K
(2)、發送請求時,瀏覽器地址欄上要展示請求引數資訊
(3)、發送請求時,請求引數資訊保存在請求頭中
(4)、回傳的資源檔案內容保存在瀏覽器的快取中
2 、POST請求方式
(1)、發送請求時,可攜帶任意數量的請求引數
(2)、發送請求時,瀏覽器地址欄上要隱藏請求引數資訊
(3)、發送請求時,請求引數資訊保存在請求體中
(4)、回傳的資源檔案內容要保護,即閱后即焚
-
Servlet規范
1、理解
Servlet是一種指定與管理動態資源檔案的規范,可以接收客戶端發送過來的請求,并回應資料給客戶端,
2、實作
通過繼承HttpServlet類,重寫doGet與doPost方法
3、多個Servlet之間的呼叫規則
(1)、重定向:
response.sendRedirect("請求地址");
(2)、請求轉發:
request.getRequestDispatcher("/資源檔案名.html").forward(request, response);
-
請求轉發與重定向區別:
1、對于請求轉發的頁面,可以是WEB-INF包中頁面;重定向的頁面,是不能為WEB-INF包中頁面,因為重定向相當于用戶再次發出一次請求,而用戶是不能直接訪問 WEB-INF中資源的,
2、請求轉發:瀏覽器發出了1次請求,得到了1次回應;請求重定向:瀏覽器發出了2次請求,得到了2次回應
3、請求轉發與重定向都不和視圖決議器一同作業,就當專案中無視圖決議器
-
Servlet規范中的四種資料共享方案
1、ServletContext物件(全域作用域物件):服務器運行期間均有效
2、Cookie物件:通過cookie保存用戶資訊,默認情況下,瀏覽器關閉,cookie銷毀
3、HttpSession物件(會話作用域物件):建立私人儲物柜
4、HttpServletRequest物件(請求作用域物件)
-
Cookie的作業原理:
Cookie是Web服務器生成,向用戶瀏覽器發送的一小段ASCII文本,當瀏覽器接收到后,會將其資訊片段以“鍵-值”對的形式保存在某個目錄下的文本檔案中,以后每次向同一個服務器發送請求的時候,瀏覽器都會發送以前存盤在本地的Cookie,瀏覽器和服務器通過HTTP協議進行通訊,Cookie便被保存在HTTP的請求部分(Set-Cookie),默認情況下,瀏覽器關閉,cookie銷毀
-
Session的作業原理
1、Session是另一種記錄客戶狀態的機制,不同的是Cookie保存在客戶端瀏覽器中,而Session保存在服務器上,
2、作業原理:
客戶端登錄完成之后,服務器會創建對應的 session,session 創建完之后,會把session 的ID發送給客戶端,客戶端再存盤到瀏覽器cookie中,這樣客戶端每次訪問服務器時,都會帶著session的ID,服務器拿到session的ID之后,在記憶體找到與之對應的session這樣就可以進行有狀態的會話,
-
當客戶端禁用cookie時,session能否繼續使用
可以使用,session只是依賴cookie存盤session的ID,當cookie被禁用了,可以使用url中添加session的ID的方式保證session能夠正常使用,
-
HttpSession物件與Cookie物件的區別
1、存盤位置
(1)、Cookie物件:存放在瀏覽器快取中(客戶端計算機)
(2)、HttpSession物件:存放在計算機的記憶體中(服務器計算機)
2、共享資料型別
(1)、Cookie物件:存盤共享資料型別只能是String
(2)、HttpSession物件:存盤共享資料型別為Object
3、資料數量
(1)、一個Cookie物件只能存盤一個共享資料
(2)、HttpSession物件可使用Map集合存盤任意數量的共享資料
4.、參照物不同:
(1)、Cookie相當于客戶在服務端【會員卡】
(2)、HttpSession相當于客戶在服務端【鑰匙】
-
JSP的底層原理:
1、JSP會代替回應物件,將Servlet中的doGet/doPost的執行結果寫入到回應體中,
2、Tomcat服務器將jsp檔案編譯成.java類,這個類繼承自HttpJspBase類,而HttpJspBase類又是Httpservlet的實作類,所以這個由服務器生成的java類是Servlet的子類,這也就解釋jsp檔案為什么能處理用戶請求,
-
JSP的九大內置物件:
1、request:封裝客戶端的請求,其中包含來自get 或 post 請求的引數;
2、response:封裝服務器對客戶端的回應;
3、pageContext:通過該物件可以獲取其他物件;
4、session:封裝用戶會話的物件;
5、application:封裝服務器運行環境的物件;
6、out:輸出服務器回應的輸出流物件;
7、config:web 應用的配置物件;
8、page:jsp頁面本身(相當于java程式中的this);
9、exception:封裝頁面拋出例外的物件,
-
Servlet與JSP的作用域物件
1 、Servlet三大域物件:
(1)、ServletContext物件(全域作用域物件)
(2)、HttpSession物件(會話作用域物件)
(3)、HttpServletRequest物件(請求作用域物件)

2 、JSP四大域物件:
(1)、ServletContext物件(全域作用域物件)
(2)、HttpSession物件(會話作用域物件)
(3)、HttpServletRequest物件(請求作用域物件)
(4)、PageContext物件(單前頁作用域物件)

-
XML的決議方式:
XML的決議方式分為四種:參考
1、DOM決議(基礎方式):
每加載一個標簽生成一個DOM物件,當所有標簽加載完畢后會自動創建一個DOM樹,瀏覽器會自動生成一個document物件,
優點:
(1)、形成了樹結構,有助于更好的理解、掌握,且代碼容易撰寫,
(2)、決議程序中,樹結構保存在記憶體中,方便修改,
缺點:
(1)、由于檔案是一次性讀取,所以對記憶體的耗費比較大,
(2)、如果XML檔案比較大,容易影響決議性能且可能會造成記憶體溢位,
2、SAX決議(基礎方式):
優點:
(1)、采用事件驅動模式,對記憶體耗費比較小,
(2)、適用于只處理XML檔案中的資料時,
缺點:
(1)、編碼比較麻煩,
(2)、很難同時訪問XML檔案中的多處不同資料,
3、JDOM決議(擴展方式):
特征:
(1)、僅使用具體類,而不使用介面,
(2)、API大量使用了Collections類,
4、DOM4J決議(擴展方式):
特征:
(1)、JDOM的一種智能分支,它合并了許多超出基本XML檔案表示的功能,
(2)、它使用介面和抽象基本類方法,
(3)、具有性能優異、靈活性好、功能強大和極端易用的特點,
(4)、是一個開放原始碼的檔案
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/412869.html
標籤:Java
