TCP提供一種面向連接的、可靠的字節(jié)流服務(wù)。其中，面向連接意味著兩個(gè)使用TCP的應(yīng)用（通常是一個(gè)客戶和一個(gè)服務(wù)器）在彼此交換數(shù)據(jù)之前必須先建立一個(gè)TCP連接。在一個(gè)TCP連接中，僅有兩方進(jìn)行彼此通信；而字節(jié)流服務(wù)意味著兩個(gè)應(yīng)用程序通過TCP鏈接交換8bit字節(jié)構(gòu)成的字節(jié)流，TCP不在字節(jié)流中插入記錄標(biāo)識符。

　　對于可靠性，TCP通過以下方式進(jìn)行保證：

• 數(shù)據(jù)包校驗(yàn)：目的是檢測數(shù)據(jù)在傳輸過程中的任何變化，若校驗(yàn)出包有錯(cuò)，則丟棄報(bào)文段并且不給出響應(yīng)，這時(shí)TCP發(fā)送數(shù)據(jù)端超時(shí)后會(huì)重發(fā)數(shù)據(jù)；
• 對失序數(shù)據(jù)包重排序：既然TCP報(bào)文段作為IP數(shù)據(jù)報(bào)來傳輸，而IP數(shù)據(jù)報(bào)的到達(dá)可能會(huì)失序，因此TCP報(bào)文段的到達(dá)也可能會(huì)失序。TCP將對失序數(shù)據(jù)進(jìn)行重新排序，然后才交給應(yīng)用層；
• 丟棄重復(fù)數(shù)據(jù)：對于重復(fù)數(shù)據(jù)，能夠丟棄重復(fù)數(shù)據(jù)；
• 應(yīng)答機(jī)制：當(dāng)TCP收到發(fā)自TCP連接另一端的數(shù)據(jù)，它將發(fā)送一個(gè)確認(rèn)。這個(gè)確認(rèn)不是立即發(fā)送，通常將推遲幾分之一秒；
• 超時(shí)重發(fā)：當(dāng)TCP發(fā)出一個(gè)段后，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段；
• 流量控制：TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出，這就是流量控制。TCP使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。

6、客戶端不斷進(jìn)行請求鏈接會(huì)怎樣？DDos(Distributed Denial of Service)攻擊？

　　服務(wù)器端會(huì)為每個(gè)請求創(chuàng)建一個(gè)鏈接，并向其發(fā)送確認(rèn)報(bào)文，然后等待客戶端進(jìn)行確認(rèn)

1)、DDos 攻擊

• 客戶端向服務(wù)端發(fā)送請求鏈接數(shù)據(jù)包
• 服務(wù)端向客戶端發(fā)送確認(rèn)數(shù)據(jù)包
• 客戶端不向服務(wù)端發(fā)送確認(rèn)數(shù)據(jù)包，服務(wù)器一直等待來自客戶端的確認(rèn)
   

2)、DDos 預(yù)防 ( 沒有徹底根治的辦法，除非不使用TCP )

• 限制同時(shí)打開SYN半鏈接的數(shù)目
• 縮短SYN半鏈接的Time out 時(shí)間
• 關(guān)閉不必要的服務(wù)

7、Get與POST的區(qū)別

　　GET與POST是我們常用的兩種HTTP Method，二者之間的區(qū)別主要包括如下五個(gè)方面：

(1). 從功能上講，GET一般用來從服務(wù)器上獲取資源，POST一般用來更新服務(wù)器上的資源；

(2). 從REST服務(wù)角度上說，GET是冪等的，即讀取同一個(gè)資源，總是得到相同的數(shù)據(jù)，而POST不是冪等的，因?yàn)槊看握埱髮Y源的改變并不是相同的；進(jìn)一步地，GET不會(huì)改變服務(wù)器上的資源，而POST會(huì)對服務(wù)器資源進(jìn)行改變；

(3). 從請求參數(shù)形式上看，GET請求的數(shù)據(jù)會(huì)附在URL之后，即將請求數(shù)據(jù)放置在HTTP報(bào)文的 請求頭 中，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連。特別地，如果數(shù)據(jù)是英文字母/數(shù)字，原樣發(fā)送；否則，會(huì)將其編碼為 application/x-www-form-urlencoded MIME 字符串(如果是空格，轉(zhuǎn)換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進(jìn)制表示的ASCII)；而POST請求會(huì)把提交的數(shù)據(jù)則放置在是HTTP請求報(bào)文的 請求體 中。

(4). 就安全性而言，POST的安全性要比GET的安全性高，因?yàn)镚ET請求提交的數(shù)據(jù)將明文出現(xiàn)在URL上，而且POST請求參數(shù)則被包裝到請求體中，相對更安全。

(5). 從請求的大小看，GET請求的長度受限于瀏覽器或服務(wù)器對URL長度的限制，允許發(fā)送的數(shù)據(jù)量比較小，而POST請求則是沒有大小限制的。

1). GET請求中URL編碼的意義

　　我們知道，在GET請求中會(huì)對URL中非西文字符進(jìn)行編碼，這樣做的目的就是為了 避免歧義?？聪旅娴睦?，

　　針對“name1=value1&name2=value2”的例子，我們來談一下數(shù)據(jù)從客戶端到服務(wù)端的解析過程。首先，上述字符串在計(jì)算機(jī)中用ASCII嗎表示為：

6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
   6E616D6531：name1 
   3D：= 
   76616C756531：value1 
   26：&
   6E616D6532：name2 
   3D：= 
   76616C756532：value2 

　　服務(wù)端在接收到該數(shù)據(jù)后就可以遍歷該字節(jié)流，一個(gè)字節(jié)一個(gè)字節(jié)的吃，當(dāng)吃到3D這字節(jié)后，服務(wù)端就知道前面吃得字節(jié)表示一個(gè)key，再往后吃，如果遇到26，說明從剛才吃的3D到26子節(jié)之間的是上一個(gè)key的value，以此類推就可以解析出客戶端傳過來的參數(shù)。

　　現(xiàn)在考慮這樣一個(gè)問題，如果我們的參數(shù)值中就包含=或&這種特殊字符的時(shí)候該怎么辦？比如，“name1=value1”，其中value1的值是“va&lu=e1”字符串，那么實(shí)際在傳輸過程中就會(huì)變成這樣“name1=va&lu=e1”。這樣，我們的本意是只有一個(gè)鍵值對，但是服務(wù)端卻會(huì)解析成兩個(gè)鍵值對，這樣就產(chǎn)生了歧義。

　　那么，如何解決上述問題帶來的歧義呢？解決的辦法就是對參數(shù)進(jìn)行URL編碼：例如，我們對上述會(huì)產(chǎn)生歧義的字符進(jìn)行URL編碼后結(jié)果：“name1=va%26lu%3D”，這樣服務(wù)端會(huì)把緊跟在“%”后的字節(jié)當(dāng)成普通的字節(jié)，就是不會(huì)把它當(dāng)成各個(gè)參數(shù)或鍵值對的分隔符。更多關(guān)于 URL編碼 的內(nèi)容，請參考我的博文《使用 URLDecoder 和 URLEncoder 對中文字符進(jìn)行編碼和解碼》，此不贅述。

8、TCP與UDP的區(qū)別

　　TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)協(xié)議屬于傳輸層協(xié)議，它們之間的區(qū)別包括：

TCP是面向連接的，UDP是無連接的；

TCP是可靠的，UDP是不可靠的；

TCP只支持點(diǎn)對點(diǎn)通信，UDP支持一對一、一對多、多對一、多對多的通信模式；

TCP是面向字節(jié)流的，UDP是面向報(bào)文的；

TCP有擁塞控制機(jī)制;UDP沒有擁塞控制，適合媒體通信；

TCP首部開銷(20個(gè)字節(jié))比UDP的首部開銷(8個(gè)字節(jié))要大；

9、TCP的擁塞處理

　　計(jì)算機(jī)網(wǎng)絡(luò)中的帶寬、交換結(jié)點(diǎn)中的緩存及處理機(jī)等都是網(wǎng)絡(luò)的資源。在某段時(shí)間，若對網(wǎng)絡(luò)中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就會(huì)變壞，這種情況就叫做擁塞。擁塞控制就是 防止過多的數(shù)據(jù)注入網(wǎng)絡(luò)中，這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不致過載。注意，擁塞控制和流量控制不同，前者是一個(gè)全局性的過程，而后者指點(diǎn)對點(diǎn)通信量的控制。擁塞控制的方法主要有以下四種：

1). 慢啟動(dòng)：不要一開始就發(fā)送大量的數(shù)據(jù)，先探測一下網(wǎng)絡(luò)的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小;

2). 擁塞避免：擁塞避免算法讓擁塞窗口緩慢增長，即每經(jīng)過一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍，這樣擁塞窗口按線性規(guī)律緩慢增長。

3). 快重傳：快重傳要求接收方在收到一個(gè) 失序的報(bào)文段 后就立即發(fā)出 重復(fù)確認(rèn)（為的是使發(fā)送方及早知道有報(bào)文段沒有到達(dá)對方）而不要等到自己發(fā)送數(shù)據(jù)時(shí)捎帶確認(rèn)?？熘貍魉惴ㄒ?guī)定，發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對方尚未收到的報(bào)文段，而不必繼續(xù)等待設(shè)置的重傳計(jì)時(shí)器時(shí)間到期。

4). 快恢復(fù)：快重傳配合使用的還有快恢復(fù)算法，當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)時(shí)，就執(zhí)行“乘法減小”算法，把ssthresh門限減半，但是接下去并不執(zhí)行慢開始算法：因?yàn)槿绻W(wǎng)絡(luò)出現(xiàn)擁塞的話就不會(huì)收到好幾個(gè)重復(fù)的確認(rèn)，所以發(fā)送方現(xiàn)在認(rèn)為網(wǎng)絡(luò)可能沒有出現(xiàn)擁塞。所以此時(shí)不執(zhí)行慢開始算法，而是將cwnd設(shè)置為ssthresh的大小，然后執(zhí)行擁塞避免算法。

10、從輸入網(wǎng)址到獲得頁面的過程

　　(1). 瀏覽器查詢 DNS，獲取域名對應(yīng)的IP地址:具體過程包括瀏覽器搜索自身的DNS緩存、搜索操作系統(tǒng)的DNS緩存、讀取本地的Host文件和向本地DNS服務(wù)器進(jìn)行查詢等。對于向本地DNS服務(wù)器進(jìn)行查詢，如果要查詢的域名包含在本地配置區(qū)域資源中，則返回解析結(jié)果給客戶機(jī)，完成域名解析(此解析具有權(quán)威性)；如果要查詢的域名不由本地DNS服務(wù)器區(qū)域解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個(gè)IP地址映射，完成域名解析（此解析不具有權(quán)威性）。如果本地域名服務(wù)器并未緩存該網(wǎng)址映射關(guān)系，那么將根據(jù)其設(shè)置發(fā)起遞歸查詢或者迭代查詢；

　　(2). 瀏覽器獲得域名對應(yīng)的IP地址以后，瀏覽器向服務(wù)器請求建立鏈接，發(fā)起三次握手；

　　(3). TCP/IP鏈接建立起來后，瀏覽器向服務(wù)器發(fā)送HTTP請求；

　　(4). 服務(wù)器接收到這個(gè)請求，并根據(jù)路徑參數(shù)映射到特定的請求處理器進(jìn)行處理，并將處理結(jié)果及相應(yīng)的視圖返回給瀏覽器；

　　(5). 瀏覽器解析并渲染視圖，若遇到對js文件、css文件及圖片等靜態(tài)資源的引用，則重復(fù)上述步驟并向服務(wù)器請求這些資源；

　　(6). 瀏覽器根據(jù)其請求到的資源、數(shù)據(jù)渲染頁面，最終向用戶呈現(xiàn)一個(gè)完整的頁面。

11、Session、Cookie 與 Application

　　Cookie和Session都是客戶端與服務(wù)器之間保持狀態(tài)的解決方案，具體來說，cookie機(jī)制采用的是在客戶端保持狀態(tài)的方案，而session機(jī)制采用的是在服務(wù)器端保持狀態(tài)的方案。

(1). Cookie及其相關(guān)API

　　Cookie實(shí)際上是一小段的文本信息?？蛻舳苏埱蠓?wù)器，如果服務(wù)器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個(gè)Cookie，而客戶端瀏覽器會(huì)把Cookie保存起來。當(dāng)瀏覽器再請求該網(wǎng)站時(shí)，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務(wù)器，服務(wù)器檢查該Cookie，以此來辨認(rèn)用戶狀態(tài)。服務(wù)器還可以根據(jù)需要修改Cookie的內(nèi)容。

(2). Session及其相關(guān)API

　　同樣地，會(huì)話狀態(tài)也可以保存在服務(wù)器端?？蛻舳苏埱蠓?wù)器，如果服務(wù)器記錄該用戶狀態(tài)，就獲取Session來保存狀態(tài)，這時(shí)，如果服務(wù)器已經(jīng)為此客戶端創(chuàng)建過session，服務(wù)器就按照sessionid把這個(gè)session檢索出來使用；如果客戶端請求不包含sessionid，則為此客戶端創(chuàng)建一個(gè)session并且生成一個(gè)與此session相關(guān)聯(lián)的sessionid，并將這個(gè)sessionid在本次響應(yīng)中返回給客戶端保存。保存這個(gè)sessionid的方式可以采用 cookie機(jī)制 ，這樣在交互過程中瀏覽器可以自動(dòng)的按照規(guī)則把這個(gè)標(biāo)識發(fā)揮給服務(wù)器；若瀏覽器禁用Cookie的話，可以通過 URL重寫機(jī)制 將sessionid傳回服務(wù)器。

(3). Session 與 Cookie 的對比

實(shí)現(xiàn)機(jī)制：Session的實(shí)現(xiàn)常常依賴于Cookie機(jī)制，通過Cookie機(jī)制回傳SessionID；

大小限制：Cookie有大小限制并且瀏覽器對每個(gè)站點(diǎn)也有cookie的個(gè)數(shù)限制，Session沒有大小限制，理論上只與服務(wù)器的內(nèi)存大小有關(guān)；

安全性：Cookie存在安全隱患，通過攔截或本地文件找得到cookie后可以進(jìn)行攻擊，而Session由于保存在服務(wù)器端，相對更加安全；

服務(wù)器資源消耗：Session是保存在服務(wù)器端上會(huì)存在一段時(shí)間才會(huì)消失，如果session過多會(huì)增加服務(wù)器的壓力。

Application（ServletContext）：與一個(gè)Web應(yīng)用程序相對應(yīng)，為應(yīng)用程序提供了一個(gè)全局的狀態(tài)，所有客戶都可以使用該狀態(tài)。

(4). Application

　　Application（Java Web中的ServletContext）：與一個(gè)Web應(yīng)用程序相對應(yīng)，為應(yīng)用程序提供了一個(gè)全局的狀態(tài)，所有客戶都可以使用該狀態(tài)。

12、SQL 注入

　　SQL注入就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。

1). SQL注入攻擊的總體思路

　　(1). 尋找到SQL注入的位置
　　(2). 判斷服務(wù)器類型和后臺數(shù)據(jù)庫類型
　　(3). 針對不通的服務(wù)器和數(shù)據(jù)庫特點(diǎn)進(jìn)行SQL注入攻擊

2). SQL注入攻擊實(shí)例

　　比如，在一個(gè)登錄界面，要求輸入用戶名和密碼，可以這樣輸入實(shí)現(xiàn)免帳號登錄：

用戶名： ‘or 1 = 1 --
密 碼：

　　用戶一旦點(diǎn)擊登錄，如若沒有做特殊處理，那么這個(gè)非法用戶就很得意的登陸進(jìn)去了。這是為什么呢?下面我們分析一下：從理論上說，后臺認(rèn)證程序中會(huì)有如下的SQL語句：String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”; 因此，當(dāng)輸入了上面的用戶名和密碼，上面的SQL語句變成：SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’。分析上述SQL語句我們知道，
username=‘ or 1=1 這個(gè)語句一定會(huì)成功；然后后面加兩個(gè)-，這意味著注釋，它將后面的語句注釋，讓他們不起作用。這樣，上述語句永遠(yuǎn)都能正確執(zhí)行，用戶輕易騙過系統(tǒng)，獲取合法身份。

3). 應(yīng)對方法

(1). 參數(shù)綁定

　　使用預(yù)編譯手段，綁定參數(shù)是最好的防SQL注入的方法。目前許多的ORM框架及JDBC等都實(shí)現(xiàn)了SQL預(yù)編譯和參數(shù)綁定功能，攻擊者的惡意SQL會(huì)被當(dāng)做SQL的參數(shù)而不是SQL命令被執(zhí)行。在mybatis的mapper文件中，對于傳遞的參數(shù)我們一般是使用#和$來獲取參數(shù)值。當(dāng)使用#時(shí)，變量是占位符，就是一般我們使用javajdbc的PrepareStatement時(shí)的占位符，所有可以防止sql注入；當(dāng)使用$時(shí)，變量就是直接追加在sql中，一般會(huì)有sql注入問題。

(2). 使用正則表達(dá)式過濾傳入的參數(shù)

13、 XSS 攻擊

　　XSS是一種經(jīng)常出現(xiàn)在web應(yīng)用中的計(jì)算機(jī)安全漏洞，與SQL注入一起成為web中最主流的攻擊方式。XSS是指惡意攻擊者利用網(wǎng)站沒有對用戶提交數(shù)據(jù)進(jìn)行轉(zhuǎn)義處理或者過濾不足的缺點(diǎn)，進(jìn)而添加一些腳本代碼嵌入到web頁面中去，使別的用戶訪問都會(huì)執(zhí)行相應(yīng)的嵌入代碼，從而盜取用戶資料、利用用戶身份進(jìn)行某種動(dòng)作或者對訪問者進(jìn)行病毒侵害的一種攻擊方式。

1). XSS攻擊的危害

盜取各類用戶帳號，如機(jī)器登錄帳號、用戶網(wǎng)銀帳號、各類管理員帳號

控制企業(yè)數(shù)據(jù)，包括讀取、篡改、添加、刪除企業(yè)敏感數(shù)據(jù)的能力

盜竊企業(yè)重要的具有商業(yè)價(jià)值的資料

非法轉(zhuǎn)賬

強(qiáng)制發(fā)送電子郵件

網(wǎng)站掛馬

控制受害者機(jī)器向其它網(wǎng)站發(fā)起攻擊

2). 原因解析

　　主要原因：過于信任客戶端提交的數(shù)據(jù)！

　　解決辦法：不信任任何客戶端提交的數(shù)據(jù)，只要是客戶端提交的數(shù)據(jù)就應(yīng)該先進(jìn)行相應(yīng)的過濾處理然后方可進(jìn)行下一步的操作。

　　進(jìn)一步分析細(xì)節(jié)：客戶端提交的數(shù)據(jù)本來就是應(yīng)用所需要的，但是惡意攻擊者利用網(wǎng)站對客戶端提交數(shù)據(jù)的信任，在數(shù)據(jù)中插入一些符號以及javascript代碼，那么這些數(shù)據(jù)將會(huì)成為應(yīng)用代碼中的一部分了，那么攻擊者就可以肆無忌憚地展開攻擊啦，因此我們絕不可以信任任何客戶端提交的數(shù)據(jù)?。?！

3). XSS 攻擊分類

(1). 反射性XSS攻擊 (非持久性XSS攻擊)

　　漏洞產(chǎn)生的原因是攻擊者注入的數(shù)據(jù)反映在響應(yīng)中。一個(gè)典型的非持久性XSS攻擊包含一個(gè)帶XSS攻擊向量的鏈接(即每次攻擊需要用戶的點(diǎn)擊)，例如，正常發(fā)送消息：

http://www.test.com/message.php?send=Hello,World！

接收者將會(huì)接收信息并顯示Hello,World；但是，非正常發(fā)送消息：

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

接收者接收消息顯示的時(shí)候?qū)?huì)彈出警告窗口！

(2). 持久性XSS攻擊 (留言板場景)

　　XSS攻擊向量(一般指XSS攻擊代碼)存儲(chǔ)在網(wǎng)站數(shù)據(jù)庫，當(dāng)一個(gè)頁面被用戶打開的時(shí)候執(zhí)行。也就是說，每當(dāng)用戶使用瀏覽器打開指定頁面時(shí)，腳本便執(zhí)行。與非持久性XSS攻擊相比，持久性XSS攻擊危害性更大。從名字就可以了解到，持久性XSS攻擊就是將攻擊代碼存入數(shù)據(jù)庫中，然后客戶端打開時(shí)就執(zhí)行這些攻擊代碼。

例如，留言板表單中的表單域

<input type=“text” name=“content” value=“這里是用戶填寫的數(shù)據(jù)”>

正常操作流程是：用戶是提交相應(yīng)留言信息 —— 將數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫 —— 其他用戶訪問留言板，應(yīng)用去數(shù)據(jù)并顯示；而非正常操作流程是攻擊者在value填寫:

<script>alert(‘foolish!’)；</script> <!--或者h(yuǎn)tml其他標(biāo)簽（破壞樣式。。。）、一段攻擊型代碼-->

并將數(shù)據(jù)提交、存儲(chǔ)到數(shù)據(jù)庫中；當(dāng)其他用戶取出數(shù)據(jù)顯示的時(shí)候，將會(huì)執(zhí)行這些攻擊性代碼。

4). 修復(fù)漏洞方針

　　漏洞產(chǎn)生的根本原因是 太相信用戶提交的數(shù)據(jù)，對用戶所提交的數(shù)據(jù)過濾不足所導(dǎo)致的，因此解決方案也應(yīng)該從這個(gè)方面入手，具體方案包括：

將重要的cookie標(biāo)記為http only, 這樣的話Javascript 中的document.cookie語句就不能
獲取到cookie了（如果在cookie中設(shè)置了HttpOnly屬性，那么通過js腳本將無法讀取到cookie信息，這樣能有效的防止XSS攻擊）；

表單數(shù)據(jù)規(guī)定值的類型，例如：年齡應(yīng)為只能為int、name只能為字母數(shù)字組合。。。。

對數(shù)據(jù)進(jìn)行Html Encode 處理

過濾或移除特殊的Html標(biāo)簽，例如: <script>, <iframe> , < for <, > for>, &quot for

過濾JavaScript 事件的標(biāo)簽，例如 “οnclick=”, “onfocus” 等等。

　　需要注意的是，在有些應(yīng)用中是允許html標(biāo)簽出現(xiàn)的，甚至是javascript代碼出現(xiàn)。因此，我們在過濾數(shù)據(jù)的時(shí)候需要仔細(xì)分析哪些數(shù)據(jù)是有特殊要求（例如輸出需要html代碼、javascript代碼拼接、或者此表單直接允許使用等等），然后區(qū)別處理！

14、OSI網(wǎng)絡(luò)體系結(jié)構(gòu)與TCP/IP協(xié)議模型

　　為了更好地了解計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)，筆者以兩篇博客的篇幅來介紹這個(gè)計(jì)算機(jī)網(wǎng)絡(luò)中最為重要的知識點(diǎn)，具體見《計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)綜述（上）》 和 《計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)綜述（下）》。下面只做簡要的總結(jié)。

　　在《計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)綜述（下）》一文中，我們知道TCP/IP與OSI最大的不同在于：OSI是一個(gè)理論上的網(wǎng)絡(luò)通信模型，而TCP/IP則是實(shí)際上的網(wǎng)絡(luò)通信標(biāo)準(zhǔn)。但是，它們的初衷是一樣的，都是為了使得兩臺計(jì)算機(jī)能夠像兩個(gè)知心朋友那樣能夠互相準(zhǔn)確理解對方的意思并做出優(yōu)雅的回應(yīng)?，F(xiàn)在，我們對OSI七層模型的各層進(jìn)行簡要的介紹：

1). 物理層

　　參考模型的最低層，也是OSI模型的第一層，實(shí)現(xiàn)了相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送，并盡可能地屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異，使其上層(數(shù)據(jù)鏈路層)不必關(guān)心網(wǎng)絡(luò)的具體傳輸介質(zhì)。

2). 數(shù)據(jù)鏈路層（data link layer）

　　接收來自物理層的位流形式的數(shù)據(jù)，并封裝成幀，傳送到上一層；同樣，也將來自上層的數(shù)據(jù)幀，拆裝為位流形式的數(shù)據(jù)轉(zhuǎn)發(fā)到物理層。這一層在物理層提供的比特流的基礎(chǔ)上，通過差錯(cuò)控制、流量控制方法，使有差錯(cuò)的物理線路變?yōu)闊o差錯(cuò)的數(shù)據(jù)鏈路，即提供可靠的通過物理介質(zhì)傳輸數(shù)據(jù)的方法。

3). 網(wǎng)絡(luò)層

　　將網(wǎng)絡(luò)地址翻譯成對應(yīng)的物理地址，并通過路由選擇算法為分組通過通信子網(wǎng)選擇最適當(dāng)?shù)穆窂健?/p>

4). 傳輸層（transport layer）

　　在源端與目的端之間提供可靠的透明數(shù)據(jù)傳輸，使上層服務(wù)用戶不必關(guān)系通信子網(wǎng)的實(shí)現(xiàn)細(xì)節(jié)。在協(xié)議棧中，傳輸層位于網(wǎng)絡(luò)層之上，傳輸層協(xié)議為不同主機(jī)上運(yùn)行的進(jìn)程提供邏輯通信，而網(wǎng)絡(luò)層協(xié)議為不同主機(jī)提供邏輯通信，如下圖所示。

　　實(shí)際上，網(wǎng)絡(luò)層可以看作是傳輸層的一部分，其為傳輸層提供服務(wù)。但對于終端系統(tǒng)而言，網(wǎng)絡(luò)層對它們而言是透明的，它們知道傳輸層的存在，也就是說，在邏輯上它們認(rèn)為是傳輸層為它們提供了端對端的通信，這也是分層思想的妙處。

5). 會(huì)話層（Session Layer）

　　會(huì)話層是OSI模型的第五層，是用戶應(yīng)用程序和網(wǎng)絡(luò)之間的接口，負(fù)責(zé)在網(wǎng)絡(luò)中的兩節(jié)點(diǎn)之間建立、維持和終止通信。

6). 表示層（Presentation Layer）：數(shù)據(jù)的編碼，壓縮和解壓縮，數(shù)據(jù)的加密和解密

　　表示層是OSI模型的第六層，它對來自應(yīng)用層的命令和數(shù)據(jù)進(jìn)行解釋，以確保一個(gè)系統(tǒng)的應(yīng)用層所發(fā)送的信息可以被另一個(gè)系統(tǒng)的應(yīng)用層讀取。

7). 應(yīng)用層（Application layer）：為用戶的應(yīng)用進(jìn)程提供網(wǎng)絡(luò)通信服務(wù)

15、TCP和UDP分別對應(yīng)的常見應(yīng)用層協(xié)議

1). TCP對應(yīng)的應(yīng)用層協(xié)議

FTP：定義了文件傳輸協(xié)議，使用21端口。常說某某計(jì)算機(jī)開了FTP服務(wù)便是啟動(dòng)了文件傳輸服務(wù)。下載文件，上傳主頁，都要用到FTP服務(wù)。

Telnet：它是一種用于遠(yuǎn)程登陸的端口，用戶可以以自己的身份遠(yuǎn)程連接到計(jì)算機(jī)上，通過這種端口可以提供一種基于DOS模式下的通信服務(wù)。如以前的BBS是-純字符界面的，支持BBS的服務(wù)器將23端口打開，對外提供服務(wù)。

SMTP：定義了簡單郵件傳送協(xié)議，現(xiàn)在很多郵件服務(wù)器都用的是這個(gè)協(xié)議，用于發(fā)送郵件。如常見的免費(fèi)郵件服務(wù)中用的就是這個(gè)郵件服務(wù)端口，所以在電子郵件設(shè)置-中?？吹接羞@么SMTP端口設(shè)置這個(gè)欄，服務(wù)器開放的是25號端口。

POP3：它是和SMTP對應(yīng)，POP3用于接收郵件。通常情況下，POP3協(xié)議所用的是110端口。也是說，只要你有相應(yīng)的使用POP3協(xié)議的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陸進(jìn)郵箱界面，直接用郵件程序就可以收到郵件（如是163郵箱就沒有必要先進(jìn)入網(wǎng)易網(wǎng)站，再進(jìn)入自己的郵-箱來收信）。

HTTP：從Web服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。

2). UDP對應(yīng)的應(yīng)用層協(xié)議

DNS：用于域名解析服務(wù)，將域名地址轉(zhuǎn)換為IP地址。DNS用的是53號端口。

SNMP：簡單網(wǎng)絡(luò)管理協(xié)議，使用161號端口，是用來管理網(wǎng)絡(luò)設(shè)備的。由于網(wǎng)絡(luò)設(shè)備很多，無連接的服務(wù)就體現(xiàn)出其優(yōu)勢。

TFTP(Trival File Transfer Protocal)：簡單文件傳輸協(xié)議，該協(xié)議在熟知端口69上使用UDP服務(wù)。

3). 圖示

16、網(wǎng)絡(luò)層的ARP協(xié)議工作原理

　　網(wǎng)絡(luò)層的ARP協(xié)議完成了IP地址與物理地址的映射。首先，每臺主機(jī)都會(huì)在自己的ARP緩沖區(qū)中建立一個(gè)ARP列表，以表示IP地址和MAC地址的對應(yīng)關(guān)系。當(dāng)源主機(jī)需要將一個(gè)數(shù)據(jù)包要發(fā)送到目的主機(jī)時(shí)，會(huì)首先檢查自己ARP列表中是否存在該IP地址對應(yīng)的MAC地址：如果有，就直接將數(shù)據(jù)包發(fā)送到這個(gè)MAC地址；如果沒有，就向本地網(wǎng)段發(fā)起一個(gè)ARP請求的廣播包，查詢此目的主機(jī)對應(yīng)的MAC地址。此ARP請求數(shù)據(jù)包里包括源主機(jī)的IP地址、硬件地址、以及目的主機(jī)的IP地址。網(wǎng)絡(luò)中所有的主機(jī)收到這個(gè)ARP請求后，會(huì)檢查數(shù)據(jù)包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此數(shù)據(jù)包；如果相同，該主機(jī)首先將發(fā)送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已經(jīng)存在該IP的信息，則將其覆蓋，然后給源主機(jī)發(fā)送一個(gè)ARP響應(yīng)數(shù)據(jù)包，告訴對方自己是它需要查找的MAC地址；源主機(jī)收到這個(gè)ARP響應(yīng)數(shù)據(jù)包后，將得到的目的主機(jī)的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息開始數(shù)據(jù)的傳輸。如果源主機(jī)一直沒有收到ARP響應(yīng)數(shù)據(jù)包，表示ARP查詢失敗。

17、IP地址的分類

　　IP地址是指互聯(lián)網(wǎng)協(xié)議地址，是IP協(xié)議提供的一種統(tǒng)一的地址格式，它為互聯(lián)網(wǎng)上的每一個(gè)網(wǎng)絡(luò)和每一臺主機(jī)分配一個(gè)邏輯地址，以此來屏蔽物理地址的差異。IP地址編址方案將IP地址空間劃分為A、B、C、D、E五類，其中A、B、C是基本類，D、E類作為多播和保留使用，為特殊地址。

　　每個(gè)IP地址包括兩個(gè)標(biāo)識碼（ID），即網(wǎng)絡(luò)ID和主機(jī)ID。同一個(gè)物理網(wǎng)絡(luò)上的所有主機(jī)都使用同一個(gè)網(wǎng)絡(luò)ID，網(wǎng)絡(luò)上的一個(gè)主機(jī)（包括網(wǎng)絡(luò)上工作站，服務(wù)器和路由器等）有一個(gè)主機(jī)ID與其對應(yīng)。A~E類地址的特點(diǎn)如下：

A類地址：以0開頭，第一個(gè)字節(jié)范圍：0~127；

B類地址：以10開頭，第一個(gè)字節(jié)范圍：128~191；

C類地址：以110開頭，第一個(gè)字節(jié)范圍：192~223；

D類地址：以1110開頭，第一個(gè)字節(jié)范圍為224~239；

E類地址：以1111開頭，保留地址

1). A類地址：1字節(jié)的網(wǎng)絡(luò)地址 + 3字節(jié)主機(jī)地址，網(wǎng)絡(luò)地址的最高位必須是“0”

　　一個(gè)A類IP地址是指， 在IP地址的四段號碼中，第一段號碼為網(wǎng)絡(luò)號碼，剩下的三段號碼為本地計(jì)算機(jī)的號碼。如果用二進(jìn)制表示IP地址的話，A類IP地址就由1字節(jié)的網(wǎng)絡(luò)地址和3字節(jié)主機(jī)地址組成，網(wǎng)絡(luò)地址的最高位必須是“0”。A類IP地址中網(wǎng)絡(luò)的標(biāo)識長度為8位，主機(jī)標(biāo)識的長度為24位，A類網(wǎng)絡(luò)地址數(shù)量較少，有126個(gè)網(wǎng)絡(luò)，每個(gè)網(wǎng)絡(luò)可以容納主機(jī)數(shù)達(dá)1600多萬臺。

　　A類IP地址的地址范圍1.0.0.0到127.255.255.255（二進(jìn)制表示為：00000001 00000000 00000000 00000000 - 01111110 11111111 11111111 11111111），最后一個(gè)是廣播地址。A類IP地址的子網(wǎng)掩碼為255.0.0.0，每個(gè)網(wǎng)絡(luò)支持的最大主機(jī)數(shù)為256的3次方-2=16777214臺。

2). B類地址: 2字節(jié)的網(wǎng)絡(luò)地址 + 2字節(jié)主機(jī)地址，網(wǎng)絡(luò)地址的最高位必須是“10”

　　一個(gè)B類IP地址是指，在IP地址的四段號碼中，前兩段號碼為網(wǎng)絡(luò)號碼。如果用二進(jìn)制表示IP地址的話，B類IP地址就由2字節(jié)的網(wǎng)絡(luò)地址和2字節(jié)主機(jī)地址組成，網(wǎng)絡(luò)地址的最高位必須是“10”。B類IP地址中網(wǎng)絡(luò)的標(biāo)識長度為16位，主機(jī)標(biāo)識的長度為16位，B類網(wǎng)絡(luò)地址適用于中等規(guī)模的網(wǎng)絡(luò)，有16384個(gè)網(wǎng)絡(luò)，每個(gè)網(wǎng)絡(luò)所能容納的計(jì)算機(jī)數(shù)為6萬多臺。

　　B類IP地址地址范圍128.0.0.0-191.255.255.255（二進(jìn)制表示為：10000000 00000000 00000000 00000000—-10111111 11111111 11111111 11111111），最后一個(gè)是廣播地址。B類IP地址的子網(wǎng)掩碼為255.255.0.0，每個(gè)網(wǎng)絡(luò)支持的最大主機(jī)數(shù)為256的2次方-2=65534臺。

3). C類地址: 3字節(jié)的網(wǎng)絡(luò)地址 + 1字節(jié)主機(jī)地址，網(wǎng)絡(luò)地址的最高位必須是“110”

　　一個(gè)C類IP地址是指，在IP地址的四段號碼中，前三段號碼為網(wǎng)絡(luò)號碼，剩下的一段號碼為本地計(jì)算機(jī)的號碼。如果用二進(jìn)制表示IP地址的話，C類IP地址就由3字節(jié)的網(wǎng)絡(luò)地址和1字節(jié)主機(jī)地址組成，網(wǎng)絡(luò)地址的最高位必須是“110”。C類IP地址中網(wǎng)絡(luò)的標(biāo)識長度為24位，主機(jī)標(biāo)識的長度為8位，C類網(wǎng)絡(luò)地址數(shù)量較多，有209萬余個(gè)網(wǎng)絡(luò)。適用于小規(guī)模的局域網(wǎng)絡(luò)，每個(gè)網(wǎng)絡(luò)最多只能包含254臺計(jì)算機(jī)。

　　C類IP地址范圍192.0.0.0-223.255.255.255（二進(jìn)制表示為: 11000000 00000000 00000000 00000000 - 11011111 11111111 11111111 11111111）。C類IP地址的子網(wǎng)掩碼為255.255.255.0，每個(gè)網(wǎng)絡(luò)支持的最大主機(jī)數(shù)為256-2=254臺。

4). D類地址:多播地址，用于1對多通信，最高位必須是“1110”

　　D類IP地址在歷史上被叫做多播地址(multicast address)，即組播地址。在以太網(wǎng)中，多播地址命名了一組應(yīng)該在這個(gè)網(wǎng)絡(luò)中應(yīng)用接收到一個(gè)分組的站點(diǎn)。多播地址的最高位必須是“1110”，范圍從224.0.0.0到239.255.255.255。

5). E類地址:為保留地址，最高位必須是“1111”

18、IP地址與物理地址

　　物理地址是數(shù)據(jù)鏈路層和物理層使用的地址，IP地址是網(wǎng)絡(luò)層和以上各層使用的地址，是一種邏輯地址，其中ARP協(xié)議用于IP地址與物理地址的對應(yīng)。

21、 常見狀態(tài)碼及原因短語

　　HTTP請求結(jié)構(gòu)： 請求方式 + 請求URI + 協(xié)議及其版本
　　HTTP響應(yīng)結(jié)構(gòu)： 狀態(tài)碼 + 原因短語 + 協(xié)議及其版本

1×× : 請求處理中，請求已被接受，正在處理2×× : 請求成功，請求被成功處理
200 OK3×× : 重定向，要完成請求必須進(jìn)行進(jìn)一步處理
301 : 永久性轉(zhuǎn)移
302 ：暫時(shí)性轉(zhuǎn)移
304 ： 已緩存4×× : 客戶端錯(cuò)誤，請求不合法
400：Bad Request,請求有語法問題
403：拒絕請求
404：客戶端所訪問的頁面不存在5×× : 服務(wù)器端錯(cuò)誤，服務(wù)器不能處理合法請求
500 ：服務(wù)器內(nèi)部錯(cuò)誤
503 ： 服務(wù)不可用，稍等
　　
　　更多關(guān)于HTTP協(xié)議的介紹請見我的博文《 圖解 HTTP：Web開發(fā)相關(guān)的一些核心基礎(chǔ)概念》。

引用

淺談HTTP中Get與Post的區(qū)別
TCP的擁塞控制
Session簡介
javaweb學(xué)習(xí)總結(jié)(十一)——使用Cookie進(jìn)行會(huì)話管理
XSS跨站腳本攻擊

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。