osi七層模型 及tcp UDP http協議
ISO/OSI
OSI（Open System Interconnect），即開放式系統互聯。 一般都叫OSI參考模型，是ISO（國際標準化組織）組織在1985年研究的網路互聯模型。該體系結構標準定義了網路互連的七層框架（物理層、資料鏈路層、網路層、傳輸層、會話層、表示層和應用層），即ISO開放系統互連參考模型。注意這僅僅是一個參考模型，實際用得更多的是更成熟的tcp/ip4層模型。
上三層總稱應用層負責使用者輸出輸入的，是控制軟體方面的。下四層總稱資料流層，負責資料傳輸的，是用來管理硬體的。
OSI參考模型中的資料傳輸過程
在OSI參考模型中，不同主機對等層之間按相應協議進行通訊，同一主機不同層之間通過介面進行通訊。除了最低層的物理層是通過傳輸介質進行物理資料傳輸外，其他對等層之間的通訊均為邏輯通訊。在這個模型中，每一層將上層傳遞過來的通訊資料加上若干控制位後再傳遞給下一層，最終由物理層傳遞到對方物理層，再逐級上傳，從而實現對等層之間的邏輯通訊，如下圖所示。
二、osi七層模型
1.物理層：建立、維護、斷開物理連線；
2.資料鏈路層：建立邏輯連線、進行硬體地址定址、差錯校驗等功能；
3.網路層：進行邏輯地址定址、實現不同網路之間的路徑選擇；
4.傳輸層：定義傳輸資料得協議埠，以及流程和差錯校驗，協議有TCP、UDP，資料包一旦離開網絡卡即進入網路傳輸層；
5.會話層：建立、管理、終止會話；
6.表示層：資料的表示、安全、壓縮；
7.應用層：網路協議與終端使用者得一個介面，協議有http ftp tftp smtp snmp dns telnet https pop3 dhcp。
通過初步的瞭解，我知道IP協議對應於網路層，TCP協議對應於傳輸層，而HTTP協議對應於應用層，三者從本質上來說沒有可比性，socket則是對TCP/IP協議的封裝和應用(程式設計師層面上)。
TCP/IP協議分層
TCP/IP協議族按照層次由上到下，層層包裝。
TCP三次握手
所謂三次握手（Three-Way Handshake）即建立TCP連線，就是指建立一個TCP連線時，需要客戶端和服務端總共傳送3個包以確認連線的建立。在socket程式設計中，這一過程由客戶端執行connect來觸發，整個流程如下圖所示：
（1）第一次握手：Client將標誌位SYN置為1，隨機產生一個值seq=J，並將該資料包傳送給Server，Client進入SYN_SENT狀態，等待Server確認。
（2）第二次握手：Server收到資料包後由標誌位SYN=1知道Client請求建立連線，Server將標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該資料包傳送給Client以確認連線請求，Server進入SYN_RCVD狀態。
（3）第三次握手：Client收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該資料包傳送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連線建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸資料了。
簡單來說，就是
1、建立連線時，客戶端傳送SYN包（SYN=i）到伺服器，並進入到SYN-SEND狀態，等待伺服器確認
2、伺服器收到SYN包，必須確認客戶的SYN（ack=i+1）,同時自己也傳送一個SYN包（SYN=k）,即SYN+ACK包，此時伺服器進入SYN-RECV狀態
3、客戶端收到伺服器的SYN+ACK包，向伺服器傳送確認報ACK（ack=k+1）,此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手，客戶端與伺服器開始傳送資料。
SYN攻擊：
在三次握手過程中，Server傳送SYN-ACK之後，收到Client的ACK之前的TCP連線稱為半連線（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址，並向Server不斷地傳送SYN包，Server回覆確認包，並等待Client的確認，由於源地址是不存在的，因此，Server需要不斷重發直至超時，這些偽造的SYN包將產時間佔用未連線佇列，導致正常的SYN請求因為佇列滿而被丟棄，從而引起網路堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連線狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：
#netstat -nap | grep SYN_RECV
TCP四次揮手
所謂四次揮手（Four-Way Wavehand）即終止TCP連線，就是指斷開一個TCP連線時，需要客戶端和服務端總共傳送4個包以確認連線的斷開。在socket程式設計中，這一過程由客戶端或服務端任一方執行close來觸發，整個流程如下圖所示：
TCP四次揮手.png由於TCP連線時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成資料傳送任務後，傳送一個FIN來終止這一方向的連線，收到一個FIN只是意味著這一方向上沒有資料流動了，即不會再收到資料了，但是在這個TCP連線上仍然能夠傳送資料，直到這一方向也傳送了FIN。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉，上圖描述的即是如此。
（1）第一次揮手：Client傳送一個FIN，用來關閉Client到Server的資料傳送，Client進入FIN_WAIT_1狀態。
（2）第二次揮手：Server收到FIN後，傳送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
（3）第三次揮手：Server傳送一個FIN，用來關閉Server到Client的資料傳送，Server進入LAST_ACK狀態。
（4）第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接著傳送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。
為什麼建立連線是三次握手，而關閉連線卻是四次揮手呢？
這是因為服務端在LISTEN狀態下，收到建立連線請求的SYN報文後，把ACK和SYN放在一個報文裡傳送給客戶端。而關閉連線時，當收到對方的FIN報文時，僅僅表示對方不再發送資料了但是還能接收資料，己方也未必全部資料都發送給對方了，所以己方可以立即close，也可以傳送一些資料給對方後，再發送FIN報文給對方來表示同意現在關閉連線，因此，己方ACK和FIN一般都會分開發送。
以上這些文字雖然很好，但是並不以理解，接下來通俗解釋一下吧！
無論多少次握手都不能滿足傳輸的絕對可靠。
TCP的核心思想：保證資料可靠傳輸
其次：保證傳輸效率。
那麼，就可以開始回答了：
為什麼要握手(為什麼不是2次握手)？
**為了保證傳輸的可靠。**
第一次握手CLIENT告訴SERVER“我將要開始傳輸資料了”。
第二次握手SERVER告訴CLIENT“我已經知道你將要傳輸資料了，我已經做好準備”。
第三次握手CLIENT告訴SERVER“我已經知道你已經知道'我知道你已經做好準備'”，SERVER端收到這個訊號，開始傳輸資料。
但是此時CLIENT並不知道SERVER已經知道“CLIENT 已經知道SERVER已經知道”(有點繞，可以忽略這一句)。
為什麼是3次而不是4次?
**為了提高傳輸的效率**
總之不管多少次握手，總會有一方不知道對方已經知道。因此為了傳輸效率，只要3次握手就認為已經可以開始傳輸資料，三次握手之後，
CLIENT和SERVER就進入ESTABLISHED狀態，開始資料傳輸。
以下有在網上盜的一幅圖，僅供參考：
TCP
TCP的目的是提供可靠的資料傳輸，並在相互進行通訊的裝置或服務之間保持一個虛擬連線。TCP在資料包接收無序、丟失或在交付期間被破壞時，負責資料恢復。它通過為其傳送的每個資料包提供一個序號來完成此恢復。記住，較低的網路層會將每個資料包視為一個獨立的單元，因此，資料包可以沿完全不同的路徑傳送，即使它們都是同一訊息的組成部分。這種路由與網路層處理分段和重新組裝資料包的方式非常相似，只是級別更高而已。
為確保正確地接收資料，TCP要求在目標計算機成功收到資料時發回一個確認（即 ACK）。如果在某個時限內未收到相應的 ACK，將重新傳送資料包。如果網路擁塞，這種重新傳送將導致傳送的資料包重複。但是，接收計算機可使用資料包的序號來確定它是否為重複資料包，並在必要時丟棄它。
TCP和UDP的區別
一、TCP是面向連結的，雖然說網路的不安全不穩定特性決定了多少次握手都不能保證連線的可靠性，但TCP的三次握手在最低限度上(實際上也很大程度上保證了)保證了連線的可靠性;而UDP不是面向連線的，UDP傳送資料前並不與對方建立連線，對接收到的資料也不傳送確認訊號，傳送端不知道資料是否會正確接收，當然也不用重發，所以說UDP是無連線的、不可靠的一種資料傳輸協議。
二、也正由於1所說的特點，使得UDP的開銷更小資料傳輸速率更高，因為不必進行收發資料的確認，所以UDP的實時性更好。知道了TCP和UDP的區別，就不難理解為何採用TCP傳輸協議的MSN比採用UDP的QQ傳輸檔案慢了，但並不能說QQ的通訊是不安全的，因為程式設計師可以手動對UDP的資料收發進行驗證，比如傳送方對每個資料包進行編號然後由接收方進行驗證啊什麼的，即使是這樣，UDP因為在底層協議的封裝上沒有采用類似TCP的“三次握手”而實現了TCP所無法達到的傳輸效率。
tcp協議和udp協議的差別 名稱…………… TCP ………………UDP 是否連線…… 面向連線 ………面向非連線 傳輸可靠性…… 可靠 …………不可靠 應用場合 ……傳輸大量資料…… 少量資料 速度 ……………慢………………… 快
簡單的說，TCP注重資料可靠性，而UDP資料傳輸快點，但安全性一般
TCP與UDP的選擇
如果比較UDP包和TCP包的結構，很明顯UDP包不具備TCP包複雜的可靠性與控制機制。與TCP協議相同，UDP的源埠數和目的埠數也都支援一臺主機上的多個應用。一個16位的UDP包包含了一個位元組長的頭部和資料的長度，校驗碼域使其可以進行整體校驗。（許多應用只支援UDP，如：多媒體資料流，不產生任何額外的資料，即使知道有破壞的包也不進行重發。）
很明顯，當資料傳輸的效能必須讓位於資料傳輸的完整性、可控制性和可靠性時，TCP協議是當然的選擇。當強調傳輸效能而不是傳輸的完整性時，如：音訊和多媒體應用，UDP是最好的選擇。在資料傳輸時間很短，以至於此前的連線過程成為整個流量主體的情況下，UDP也是一個好的選擇，如：DNS交換。把SNMP建立在UDP上的部分原因是設計者認為當發生網路阻塞時，UDP較低的開銷使其有更好的機會去傳送管理資料。TCP豐富的功能有時會導致不可預料的效能低下，但是我們相信在不遠的將來，TCP可靠的點對點連線將會用於絕大多數的網路應用。
HTTP
HTTP屬於TCP/IP應用層協議,應用層協議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用層協議。
WEB使用HTTP協議作應用層協議，以封裝HTTP文字資訊，然後使用TCP/IP做傳輸層協議將它發到網路上。
HTTP協議是建立在請求/響應模型上的。首先由客戶建立一條與伺服器的TCP連結，併發送一個請求到伺服器，請求中包含請求方法、URI、協議版本以及相關的MIME樣式的訊息。伺服器響應一個狀態行，包含訊息的協議版本、一個成功和失敗碼以及相關的MIME式樣的訊息。
HTTP/1.0為每一次HTTP的請求/響應建立一條新的TCP連結，因此一個包含HTML內容和圖片的頁面將需要建立多次的短期的TCP連結。一次TCP連結的建立將需要3次握手。但HTTP/1.1裡面有所改變,可以在一次連線中處理多個請求，並且多個請求可以重疊進行，不需要等待一個請求結束後再發送下一個請求。
由於HTTP在每次請求結束後都會主動釋放連線，因此HTTP連線是一種“短連線”，要保持客戶端程式的線上狀態，需要不斷地向伺服器發起連線請求。通常的做法是即時不需要獲得任何資料，客戶端也保持每隔一段固定的時間向伺服器傳送一次“保持連線”的請求，伺服器在收到該請求後對客戶端進行回覆，表明知道客戶端“線上”。若伺服器長時間無法收到客戶端的請求，則認為客戶端“下線”，若客戶端長時間無法收到伺服器的回覆，則認為網路已經斷開。
工作特點：
1.基於B/S模型；
2.通訊開銷小，簡單快速，傳輸成本低；
3.使用靈活，可使用超文字傳輸協議；
4.節省傳輸時間；
5.無狀態；
工作原理：
客戶端傳送請求給伺服器，建立一個tcp連線，指定埠號，預設80，連線到伺服器，伺服器監聽到瀏覽器請求，一旦聽到客戶端請求，分析請求型別後，伺服器會向客戶端返回狀態資訊和資料內容；
http協議狀態碼
成功2XX 成功處理了請求的狀態碼。
200 伺服器已成功處理了請求並提供了請求的網頁。
204 伺服器成功處理了請求，但沒有返回任何內容。
重定向3XX 每次請求中使用重定向不要超過 5 次。
301 請求的網頁已永久移動到新位置。當URLs發生變化時，使用301程式碼。搜尋引擎索引中儲存新的URL。
302 請求的網頁臨時移動到新位置。搜尋引擎索引中儲存原來的URL。
304 如果網頁自請求者上次請求後沒有更新，則用304程式碼告訴搜尋引擎機器人，可節省頻寬和開銷。
客戶端錯誤4XX 表示請求可能出錯，妨礙了伺服器的處理。
400 伺服器不理解請求的語法。
403 伺服器拒絕請求。
404 伺服器找不到請求的網頁。伺服器上不存在的網頁經常會返回此程式碼。
410 請求的資源永久刪除後，伺服器返回此響應。該程式碼與 404（未找到）程式碼相似，
但在資源以前存在而現在不存在的情況下，有時用來替代404 程式碼。如果資源已永久刪除，應當使用 301 指定資源的新位置。
伺服器錯誤5XX 表示伺服器在處理請求時發生內部錯誤。這些錯誤可能是伺服器本身的錯誤，而不是請求出錯。
500 伺服器遇到錯誤，無法完成請求。
503 伺服器目前無法使用（由於超載或停機維護）。通常，這只是暫時狀態
HTTP連結的特點
HTTP協議即超文字傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。
HTTP連線最顯著的特點是客戶端傳送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連線。從建立連線到關閉連線的過程稱為“一次連線”。
利用Socket建立網路連線的步驟
建立Socket連線至少需要一對套接字，其中一個運行於客戶端，稱為ClientSocket ，另一個運行於伺服器端，稱為ServerSocket 。
套接字之間的連線過程分為三個步驟：伺服器監聽，客戶端請求，連線確認。
1。伺服器監聽：伺服器端套接字並不定位具體的客戶端套接字，而是處於等待連線的狀態，實時監控網路狀態，等待客戶端的連線請求。
2。客戶端請求：指客戶端的套接字提出連線請求，要連線的目標是伺服器端的套接字。為此，客戶端的套接字必須首先描述它要連線的伺服器的套接字，指出伺服器端套接字的地址和埠號，然後就向伺服器端套接字提出連線請求。
3。連線確認：當伺服器端套接字監聽到或者說接收到客戶端套接字的連線請求時，就響應客戶端套接字的請求，建立一個新的執行緒，把伺服器端套接字的描述發給客戶端，一旦客戶端確認了此描述，雙方就正式建立連線。而伺服器端套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連線請求套接字
TCP用主機的IP地址加上主機上的埠號作為TCP連線的端點，這種端點就叫做套接字（socket）或插口。套接字用（IP地址：埠號）表示。它是網路通訊過程中端點的抽象表示，包含進行網路通訊必需的五種資訊：連線使用的協議，本地主機的IP地址，本地程序的協議埠，遠地主機的IP地址，遠地程序的協議埠。
套接字，是支援TCP/IP的網路通訊的基本操作單元，可以看做是不同主機之間的程序進行雙向通訊的端點，簡單的說就是通訊的兩方的一種約定，用套接字中的相關函式來完成通訊過程。非常非常簡單的舉例說明下:Socket=Ip address+ TCP/UDP + port。
分類
常用的TCP/IP協議的3種套接字型別如下所示。流式套接字（SOCK_STREAM）：流式套接字用於提供面向連線、可靠的資料傳輸服務。該服務將保證資料能夠實現無差錯、無重複傳送，並按順序接收。流式套接字之所以能夠實現可靠的資料服務，原因在於其使用了傳輸控制協議，即TCP（The Transmission Control Protocol）協議。資料報套接字（SOCK_DGRAM）：資料報套接字提供了一種無連線的服務。該服務並不能保證資料傳輸的可靠性，資料有可能在傳輸過程中丟失或出現數據重複，且無法保證順序地接收到資料。資料報套接字使用UDP（User Datagram Protocol）協議進行資料的傳輸。由於資料報套接字不能保證資料傳輸的可靠性，對於有可能出現的資料丟失情況，需要在程式中做相應的處理。原始套接字（SOCK_RAW）：原始套接字(SOCKET_RAW)允許對較低層次的協議直接訪問，比如IP、 ICMP協議，它常用於檢驗新的協議實現，或者訪問現有服務中配置的新裝置，因為RAW SOCKET可以自如地控制Windows下的多種協議，能夠對網路底層的傳輸機制進行控制，所以可以應用原始套接字來操縱網路層和傳輸層應用。比如，我們可以通過RAW SOCKET來接收發向本機的ICMP、IGMP協議包，或者接收TCP/IP棧不能夠處理的IP包，也可以用來發送一些自定包頭或自定協議的IP包。網路監聽技術很大程度上依賴於SOCKET_RAW原始套接字與標準套接字（標準套接字指的是前面介紹的流式套接字和資料報套接字）的區別在於：原始套接字可以讀寫核心沒有處理的IP資料包，而流式套接字只能讀取TCP協議的資料，資料報套接字只能讀取UDP協議的資料。因此，如果要訪問其他協議傳送資料必須使用原始套接字。連線方式
應用層通過傳輸層進行資料通訊時，TCP和UDP會遇到同時為多個應用程式程序提供併發服務的問題本文轉載多處，時間緊急，沒有過多整理，敬請包涵！！