開端
最近開始實習了，今天把學習的知識做個小結。第一次使用CSDN，今天練習一下，順便把一周學的東西消化整理一下。本周學的東西主要有ONVIF協定、嘗試使用WireShark抓包、TCP\IP五層網絡結構的了解。
ONVIF協定
ONVIF标準将為網絡視訊裝置之間的資訊交換定義通用協定，包括裝置搜尋、實時視訊、音頻、中繼資料和控制資訊等。
其中裝置的管理和控制定義的接口都以WebService的形式給出，服務端與用戶端的資料互動采用soap協定，soap協定其實就是以HTTP協定為基礎的一種更上層的應用協定，也可以說soap協定是一種格式。
其中，視訊的配置資訊（比如：分辨率、幀率）都可以使用soap協定（格式的文本文檔）進行修改，每一個改動都可以看作為一個函數，而函數的接口都是以XML格式定義的。還有裝置的控制資訊（比如：PTZ（雲台控制，控制攝像頭的上下左右移動））都是以soap協定為基礎的，最後都是通過HTTP協定轉發（TCP傳輸）。
1.視訊配置資訊和裝置控制資訊使用soap協定定義接口（XML格式），使用HTTP傳輸。
我在NVR上面做了一個實驗，修改了某個攝像頭的分辨率，碼流格式以及幀率。然後點選了Save。最後用Wieshark抓了一些的包（都是HTTP協定的）。從這個地方也反映了，soap協定就是一種雙方通信的文本格式，最終都是以HTTP協定為基礎進行傳輸的。其中就有下圖的兩個接口資訊（函數接口），GetVideoEncoder裡面包含了我需要修改的視訊分辨率、碼流格式等資訊。最終通過SetVideoConfiguration…來儲存我的修改動作。抓包的資料就不上傳了。。。
2.RTSP媒體碼流控制協定
RTSP是成熟的媒體碼流控制協定，RTSP(Real-TimeStream Protocol )是一種基于文本的應用層協定，在文法及一些消息參數等方面，RTSP協定與HTTP協定類似。
RTSP被用于建立的控制媒體流的傳輸，它為多媒體服務扮演“網絡遠端控制”的角色。盡管有時可以把RTSP控制資訊和媒體資料流交織在一起傳送，但一般情況RTSP本身并不用于轉送媒體流資料。媒體資料的傳送可通過RTP/RTCP等協定來完成。
一次基本的RTSP操作過程是:
首先，用戶端連接配接到流伺服器并發送一個RTSP描述指令（DESCRIBE）。
流伺服器通過一個SDP描述來進行回報，回報資訊包括流數量、媒體類型等資訊。
用戶端在分析該SDP描述，并為會話中的每一個流發送一個RTSP建立指令(SETUP)，
RTSP建立指令告訴伺服器用戶端用于接收媒體資料的端口。
流媒體連接配接建立完成後，用戶端發送一個播放指令(PLAY)，
伺服器就開始在UDP上傳送媒體流（RTP包）到用戶端。
在播放過程中用戶端還可以向伺服器發送指令來控制快進、快退和暫停等。
最後，用戶端可發送一個終止指令(TERADOWN)來結束流媒體會話。具體過程如下圖
現在對ONVIF協定的流程算是有個大概的了解。下周準備跟進代碼，從代碼上再來了解整個流程。=-=
Wireshark 抓包分析HTTP、TCP\IP三次握手過程
1.由TCP/IP的五層模型可知（應用層、傳輸層、網絡層、鍊路層、實體層）、HTTP是屬于應用層的協定，TCP協定屬于傳輸層（面向連接配接的可靠傳輸協定）、UDP協定同樣屬于傳輸層（但是UDP是不可靠傳輸協定），IP協定是屬于網路層。
2.HTTP(超文本傳輸協定)是一個 用戶端和 伺服器端請求和應答的标準（TCP）,屬于應用層協定。
3.TCP是一種面向連接配接的可靠傳輸協定，它在每次開始傳輸資料之前都需要進行三次握手，以便确認可靠連接配接。三次握手過程如下所示。
4.用WireShark 抓包分析三次握手過程如下：（實驗環境Client<155>,server<19>）
（1）用戶端向服務端發送連接配接請求
其中，seq是目前發送資料的序列号（SYN置為1），第一幀發送序列号為0。也就是說用戶端此時從序号為0的地方向服務端發資料，資料長度為0（請求幀，不發送資料）。
（2）服務端向用戶端發送确認幀
從圖中可以看到服務端向用戶端發送的消息（SYN置為1，ACK置為1）為，seq=0,也就是說服務端向用戶端發送資料的起點為序列号0，資料長度為0（不發送資料），ack=1,表明我（服務端）收到了你從序号為0的地方發送的資料長度為0的資料（0+1）。
（3）用戶端再次向服務端發送确認幀
從圖中可以看到，用戶端再次向服務端發送了确認信号（ACK置為1），意思就是說，我收到了你的确認信号，我們可以開始建立可靠的連接配接通道了。确認幀中，seq=1,ack=1,len=0，表示為我現在向你（服務端）發送資料的起點是序号為1的地方，資料長度為0，并且我還收到了你起點為序号0，長度為0的資料。
5.HTTP協定開始請求POST消息
（1）用戶端開始向服務端POST http消息
從圖中可以看到，用戶端（155）開始向服務端發送POST請求，seq=1，ack=1，len=4635。（注：從圖中也可以看到TCP/IP協定中的五層，有HTTP（應用層）、TCP（傳輸層）、IPv4（網絡層），Ethernet（鍊路層））。seq=1，表示用戶端開始從起點序号為1的地方向服務端發送長度為4635位元組的資料；ack=1，表示用戶端确認了從服務端收到的資料。
另：從之前三次握手的消息中可以看到，用戶端和服務端都規定了MSS=1460，其中MSS是每一個TCP封包段中資料字段的最大長度，它不包括TCP協定的幀頭資料。是以可以肯定的是4635位元組的資料肯定分包發送的（如果不支援分包發送，資料傳輸就會失敗）
（2）服務端開始向用戶端發送收到消息的确認資訊
從圖中可以看到，服務端向用戶端發送的消息表示：ack=1461，表明我已經收到了你發送的1461-1=1460位元組的資料了，seq=1,len=0表明我（服務端）沒有發送資料給你。
（3） 服務端繼續向用戶端發送收到消息的确認資訊
從這張圖中可以看到，服務端繼續向用戶端發送确認消息，ack=4636，表明我已經收到了你發送的4636-1=4635位元組的資料了（也就是說服務端已經收到了用戶端發送的全部資料了）。
一開始認為有些奇怪？，居然不是用戶端每發送一幀資料包，服務端就發送一幀确認收到資料的消息。此處暫時存疑。seq=1，len=0，表明服務端此時任然沒有向用戶端發送任何資料。
（4）服務端開始給用戶端發送資料
從圖中可以看到，PSH和ACK都被置為1了，PSH表示服務端此時需要将此封包段發送出去，且接收方（用戶端）受到了PSH置為1 的封包以後，就盡快的傳遞應用程序，而不是等到整個緩存區滿了以後再開始向上傳遞。此時ack=4636，表明服務端已經完全收到了用戶端發送的資料了（以下再不贅叙了）；seq=1，len=111，表明服務端開始向用戶端發送起點序号為1，長度為111位元組的資料了；TCP Segment of a reassembled PDU ，表明我（服務端）要發送的資料是分段發送的TCP資料包。
（5 ）服務端繼續分段發送資料給用戶端
從圖中可以看到，seq=112，len=1460，表明，服務端已經發送了（112-1）111位元組的資料到用戶端了，接下來要發送起點為112 ，長度為1460位元組的資料給用戶端了。ack=4636，同上不再解釋。
（6）用戶端向服務端發送收到資料的确認消息
從圖中可以看到的，ack=1572，表明我已經收到了你發送的共1572-1=1571自己的資料了，1571位元組的資料也就是服務端已經向用戶端成功得發送的前兩幀資料（分别是第一幀111位元組和第二幀1460位元組的資料），此處也可以佐證，其實接受方（此時為用戶端）并不是每收到一幀資料就會發送一幀确認資訊給發送方（服務端），可以回答第三小節的那個疑問。seq=4636，len=0，表明此時用戶端向服務端發送起點從4636開始的0位元組資料（已經發送了4635位元組的資料了）。
（7）服務端繼續向用戶端發送分段資料
從圖中可以看到，seq=1572，len=1460，表明服務端向用戶端發送起點序号為1572，長度為1460位元組的資料給用戶端，同時也帶着分段發送的标志。ack=4636，同上不再解釋。
（8）服務端向用戶端發送最後的分段資料
從圖中可以看到，最後這一幀服務端發送給用戶端你的資料其實是一個http協定的消息（其實http協定是憑借TCP傳輸的）。seq=3032，len=1420，表明表明服務端向用戶端發送起點序号為3032（1+111+1460+1460），長度為1420位元組的資料給用戶端。四段分段資料的長度分别為111位元組、1460位元組、1460位元組、1420位元組，共4451位元組資料 已經發送給了用戶端。ack=4636，同上不再解釋。
（9）用戶端最後發送收到全部資料的确認消息給服務端
從圖中可以看到，ack=4453(4451+1+1)，表明用戶端已經全部收到了服務端剛剛發送的資料了。此時seq=4636，len=0，不再解釋了。。。。
到此為止，我用WireShark抓包工具分析了TCP的三次握手過程，以及TCP傳輸資料的過程，發現了一些和想象中不一樣的知識點了，也越發覺得WireShark的強大。