了解網絡安全行業的都知道，網絡安全協議是營造網絡安全環境的基礎，是構建安全網絡的關鍵技術。常見的網絡協議如HTTP協議、TCP/IP協議、FTP協議等。

如果你想進入網安行業，這些協議都是需要重點要學習和了解的，這也將是決定你的安全技術瓶頸高低的一個重要因素。

那麼今天安仔就跟大家簡單介紹下，我們在做網絡安全工作中，常見到的幾個協議；

HTTP協議

舉個栗子，老張喜歡看島國小片，時常泡在論壇上和網友交流最新資訊，老張是通過瀏覽器瀏覽網頁的，而瀏覽器就是藉助HTTP協議與論壇服務器溝通交流。

FTP協議

還是老張，老張購買了該網站的會員，可以無限制下載高清小片，老張是通過瀏覽器下載影音文件的，瀏覽器是藉助FTP協議與文件下載服務器溝通交流。

SMTP協議

近10個G的高清文件，老張心潮澎湃打開文件，傻了，“孫悟空大戰白骨精”映入眼帘。。。老張怒了，打開電子郵件客戶端寫投訴郵件，怒斥不良網站的欺詐行為！而電子郵件客戶端是藉助SMTP協議與郵件服務器溝通交流。

通常稱與人類直接打交道的協議，叫應用層（Application）協議，或者業務層協議。

上文的三個協議對應三種業務：

· 瀏覽網頁 –HTTP

· 下載文件 –FTP

· 發送郵件 –SMTP

通俗地說，應用層協議，如同人類的小秘書兼翻譯，用服務器可以聽得懂的語言與服務器溝通。

假設服務器只會SMTP語言，老張使用只會FTP語言的小翻譯來和服務器嘮嗑，就會呈現一幅“雞同鴨講”的滑稽畫面。而老張使用會SMTP語言的小翻譯就可以順暢地溝通。

但應用層協議，不過是人類的小翻譯，只擅長翻譯工作，其它的啥也不會！

HTTP、FTP、SMTP三個小翻譯，能把老張的需求翻譯成由“0”、“1”組成的小串串，簡稱應用數據塊。

那麼，問題來了，

1. 應用數據塊如何在浩瀚的互聯網準確無誤找到目的地？

2. 服務器回應數據塊如何在浩瀚的互聯網準確無誤地返回？

3. 應用數據塊在到達目的地之前丟失了，如何處理？

4. 服務器回應數據塊旅途中丟失了，如何處理？

這些問題在TCP/IP協議面前，都不再是問題！

TCP/IP協議就是為了解決這些問題而誕生的！！！

IP協議

在應用數據塊的外層寫上目的地IP地址，使得應用數據塊可以找到目的地，這樣就解決問題1。

還會在應用數據塊的外層寫上源IP地址，使得服務器回應數據塊返回源主機，這樣就解決問題2。

抬杠的同學會說，應用數據塊外層寫上目的IP地址，就一定可以到達目的地？不一定吧！

把老張的網線拔了、無線關了、移動網絡4G也關了，把老張的所有訪問互聯網的通道全關閉了，應用數據塊還能到達目的地哇？

那肯定不能到達，神仙來了也愛莫能助！

所以在這裡這種強調兩點：

· 底層物理網絡的連通性是IP能否正常工作的前提

· IP路由表在全球路由器里完成了同步

即使有了這兩個前提條件，也不能100%保證IP報文能夠到達目的地！

信號傳輸過程失真造成丟包、網絡發生擁堵而丟包。。。

我們還需要一個協議，這個協議需要有以下特質：

· 當丟包發生時，能夠自動修復丟包，而無需人的手動干預

· 能夠智能感知網絡的擁堵情況，網絡空閑時，盡最大速率發包；網絡擁堵時，降低速率發包，不給互聯網添堵

滿足這個特質的協議，它的名字叫TCP協議。

TCP協議

TCP協議也不是什麼大神，不過是一個任勞任怨的流量調度員。說到底它就有一個本事：

確認機制！

憑着這個看家本領，TCP可以保證應用數據的可靠傳輸。

也正是這個確認機制，讓千千萬萬個學習TCP協議的同學，苦苦掙扎痛不欲生！

但願有同學讀完這篇文章，快速脫離苦海。。。

TCP確認機制

通俗地說，TCP會對發出的數據包（以下簡稱包裹）進行編號，如同快遞的快遞單號一樣。對方TCP收到包裹，會回復一個確認消息，確認收到了該編號的包裹了。

這非常好理解，生活里這樣的故事每天都在發生。男生給異地的女友快遞一個包裹，記下快遞單號123456，過兩天女友回復一個消息，快遞單號123456已收到！

有同學會說，確認機制可以理解，TCP發數據就發數據，但為何TCP發數據之前需要連接？

在互聯網上可以找到各種各樣的解釋，而我的觀點是：

雙方通過TCP連接，分享彼此的應用數據塊第一個字節的原點序號。

如果TCP沒有提前分享，接收方不知道接收的數據是否是第一個包。

如果不是第一個包，接收方的TCP卻將該數據包提交給應用程序，應用程序壓根無法理解。

為何無法理解？

應用程序以為是第一個包，其實並不是，應用程序的小翻譯（HTTP/FTP/SMTP）瞬間懵逼，風雨中瑟瑟發抖。。。

分享了原點序列號，即使第二個、第三個數據包先到達目的地，而第一個數據包姍姍來遲的情況，接收方的TCP可以耐心等待第一個數據包的到來，然後按序將數據包提交給應用程序。這樣應用程序的小翻譯就會秒懂。。。

有了TCP協議的幫助，即使老張的網線拔掉了一段時間，稍後再插入，恢復了網絡連通性，老張中斷的文件下載任務可以繼續工作，而無需老張重新下載。

UDP協議

UDP有點像街頭的郵筒，應用程序的數據包扔進郵筒就好了，就耐心地等待數據包到達目的地。但扔進郵筒之前，需要寫好以下信息：

· 收件人的地址（目的IP）

· 收件人的姓名（目的端口號）

· 寄件人地址（源IP）

· 寄件人姓名（源端口號）

IP司機會瞬間地將郵筒里的信件，運往世界各個角落。

比較奢侈的是，一個IP司機運一件信件。

文章開頭的老張，其實一直在使用UDP協議，只是UDP協議不和老張直接打交道，老張覺察不到而已。

但老張使用的瀏覽器、郵件客戶端卻一直和UDP協議直接打交道。老張要下載文件，首先要域名解析獲得服務器的IP地址，而完成域名解析任務的是DNS協議。

DNS協議

DNS協議將自己的域名解析請求報文扔到UDP郵筒里，被IP司機運輸到域名服務器家中，服務器返回域名解析應答，同樣通過UDP郵筒郵寄服務。