HTTP協議
老王喜歡看島國小片，時常泡在論壇上和網友交流最新資訊，老王是通過瀏覽器瀏覽網頁的，而瀏覽器是藉助HTTP協議與論壇服務器溝通交流。
FTP協議
老王購買了該網站的會員，可以無限制下載高清小片，老王是通過瀏覽器下載影音文件的，瀏覽器是藉助FTP協議與文件下載服務器溝通交流。
SMTP協議
近10個G的高清文件，老王心潮澎湃打開文件，傻了，“孫悟空大戰白骨精”映入眼簾。。。老王怒了，打開電子郵件客戶端寫投訴郵件，怒斥不良網站的欺詐行為！電子郵件客戶端是藉助SMTP協議與郵件服務器溝通交流。
通常稱與人類直接打交道的協議，叫應用層（Application）協議，或者業務層協議。上文的三個協議對應三種業務：
瀏覽網頁下載文件發送郵件
通俗地說，應用層協議，如同人類的小秘書兼翻譯，用服務器可以聽得懂的語言與服務器溝通。
假設服務器只會SMTP語言，老王使用只會FTP語言的小翻譯來和服務器嘮嗑，就會呈現一幅“雞同鴨講”的滑稽畫面。而老王使用會SMTP語言的小翻譯就可以順暢地溝通。
但應用層協議，不過是人類的小翻譯，只擅長翻譯工作，其它的啥也不會！
HTTP、FTP、SMTP三個小翻譯，能把老王的需求翻譯成由“0”、“1”組成的小串串，簡稱應用數據塊。
問題來了，
應用數據塊如何在浩瀚的互聯網準確無誤找到目的地？服務器回應數據塊如何在浩瀚的互聯網準確無誤地返回？應用數據塊在到達目的地之前丟失了，如何處理？服務器回應數據塊旅途中丟失了，如何處理？
這些問題在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郵筒郵寄服務。