1、WWW伺服器和瀏覽器之間採取什麼協議進行通信。
採用超文本文件傳輸協議（即http）進行通信
HTTP是一個屬於應用層的面向對象的協議，由於其簡捷、快速的方式，適用於分布式超媒體信息系統。它於1990年提出，經過幾年的使用與發展，得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規范化工作正在進行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經提出。
2、HTTP是通信協議嗎
HTTP/1.0和HTTP/1.1都把TCP作為底層的傳輸協議。HTTP客戶首先發起建立與伺服器TCP連接。一旦建立連接，瀏覽器進程和伺服器進程就可以通過各自的套接字來訪問TCP。如前所述，客戶端套接字是客戶進程和TCP連接之間的「門」，伺服器端套接字是伺服器進程和同一TCP連接之間的「門」。客戶往自己的套接字發送HTTP請求消息，也從自己的套接字接收HTTP響應消息。類似地，伺服器從自己的套接字接收HTTP請求消息，也往自己的套接字發送HTTP響應消息。客戶或伺服器一旦把某個消息送入各自的套接字，這個消息就完全落入TCP的控制之中。TCP給HTTP提供一個可靠的數據傳輸服務;這意味著由客戶發出的每個HTTP請求消息最終將無損地到達伺服器，由伺服器發出的每個HTTP響應消息最終也將無損地到達客戶。
Http協議一定通過指定的埠，80，所以一般計算機上不會限制這個埠，所以Http協議能夠順利通過所有機器上的防火牆。而使用Socket編程的話，就需要自己指定特定的埠，那麼很可能這個埠是在某個環境中禁用的，那麼就無法穿透防火牆。IIS使用的是80埠，也就是這個程序一直在監聽著這個埠。一旦發現有人要建立到這個埠的連接，他就會響應，然後建立連接。這里說的連接都是短連接。所以你對伺服器上的網址的請求，都是通過80埠送到網站程序的。然後通過這個埠發送的客戶端瀏覽器。
3、做linux系統上的數據通訊伺服器一般採用什麼協議，協議的具體內容是什麼
SNMP簡單網路管理協議。一般伺服器監控系統都採用這種協議通訊
4、如何設計客戶端與伺服器雙向通信協議
1.
報文頭：
l
版本號：
10個字元，以Ver開頭，例如：Ver1.0.0.0＝Ver1000。
l
報文類型(命令字)：
最長不超過20個字元。
l
報文驅動者：
客戶端（當前登錄的帳號），服務端（當前伺服器名）（最長不超過20個字元）。
l
有無參數指示器：
當有參數時，指示器為1，當無參數時，指示器為0。目的是加快解析速度。
l
報文長度：
最長不超過10個字元
l
參數體：
長度可變，但是報文頭＋參數體不超過2K位元組，（相當於2048個char型數據，其中連命令字之間的「，「也包括在裡面。）參數與參數之間應用「，」隔開，參數體最大長度為1024個位元組，相當於1K
l
整體報文格式：
版本號，報文類型，報文驅動者，參數指示器，報文長度，Value（參數1，參數2，。。。。。。。）
例如：
ABC伺服器認證請求的報文：
Ver1000,Login,ABC,0,報文長度,Value（）
ABC客戶端登錄的報文：
Ver1000,Login,ABC,1,報文長度,Value（賬號，密碼，IP地址）
l
報文結構體：
Struct
Server/CustomMessage
{
char
m_cVersion[10]; //版本號
char m_cCommandType[20]; //報文類型
char m_cDriver[20]; //報文驅動者
char m_cValueSwitch; //參數指示器
char m_cMessageLen[10]; //報文長度
char m_cInputValue[1024]; //參數體
}
2.
具體的報文
定義：－＞：表示發向那裡。
為了明了，以及方便，直接將參數填入結構體內。
設定伺服器為ABC，客戶端為CDE，Sizeof返回值為字元串。
在「」內表示值為字元串
參數體以Value開頭的字元串。
客戶端的登錄與認證
（命令字與參數）
1、 伺服器－＞客戶端：要求客戶端把賬號、密碼等信息傳過來。
GetLogin（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「GetLogin」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
2、 伺服器＜－客戶端：客戶端上傳賬號、密碼等信息。
Login（賬號，密碼，IP地址）
struct CustomMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「Login」;
m_cDriver=「CDE」;
m_cValueSwitch=1;
m_cMessageLen=sizeof(CustomMessage);
m_cInputValue=「Value（賬號，密碼，IP地址）」;
}
3、 伺服器－＞客戶端：錯誤提示，表示賬號錯誤，一般為無此賬號。
AccountError（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「AccountError」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
4、 伺服器－＞客戶端：錯誤提示，表示賬號對，但密碼不對。
PasswordError（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「PasswordError」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
5、 伺服器－＞客戶端：錯誤提示，表示帳號被封，請和管理人員聯系。
BlockAccount（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「BlockAccount」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
6、 伺服器－＞客戶端：錯誤提示，表示已有相同的帳號登陸。
HaveSameAccount（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「HaveSameAccount」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
7、 伺服器＜－客戶端：客戶端已顯示錯誤提示，並將自己與伺服器斷開
ErrorMsgReceive（）
struct CustomMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「ErrorMsgReceive」;
m_cDriver=「CDE」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(CustomMessage);
m_cInputValue=NULL;
}
8、 伺服器－＞客戶端：客戶端已通過伺服器的認證，伺服器向客戶端發送帳號，一次最多40個，估計1K左右。
SendCustomList（客戶端的賬號1，客戶端賬號2，。。。。。。。）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「SendCustomList」;
m_cDriver=「ABC」;
m_cValueSwitch=1;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=「Value（客戶端的賬號1，客戶端賬號2，。。。。。。。）」;
}
9、 伺服器＜－客戶端：表示40個賬號已收到
SendCustomOk（）
struct CustomMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「SendCustomOk」;
m_cDriver=「CDE」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(CustomMessage);
m_cInputValue=NULL;
}
10、
伺服器－＞客戶端：表示伺服器把當前已接入進的所有客戶賬號發送完畢
SendCustomEnd（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「SendCustomEnd」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
11、
伺服器－＞客戶端：向當前已連接上的所有的客戶端發送刷新消息，客戶端和伺服器會重復9、10、11的動作。
FlashCustomList（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「FlashCustomList」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=「Value（客戶端的賬號1，客戶端賬號2，。。。。。。。）」;
}
12、
伺服器＜－客戶端：表示向某個客戶發送消息。
Message（對方客戶端帳號，自己客戶端帳號，客戶信息）
struct CustomMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「Message」;
m_cDriver=「CDE」;
m_cValueSwitch=1;
m_cMessageLen=sizeof(CustomMessage);
m_cInputValue=「Value（對方客戶端帳號，自己客戶端帳號，客戶信息）」;
}
13、
伺服器－＞客戶端：轉發某個客戶端的消息給另一個客戶端。
Message（對方客戶端帳號，客戶信息）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「Message」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=「Value（對方客戶端帳號，客戶信息）」;
}
5、網路伺服器通信協議用用什麼來識別高層服務
1.檢查網路是否穩定
2.查看伺服器是否正在維護
3.使用殺毒工具清理緩存
4.更新軟體版本
6、從伺服器端向客戶端推送信息採用什麼協議實現(基於HTTP方式)?
但是這種情況的確存在，例如Comet架構。
Dojo Foundation定義了一套Bayeux協議專門從事這種場景下的使用。
通常，要實現瀏覽器和伺服器之間的雙工通訊，需要建立長連接，並通過非同步調用來實現。
Bayeux也被稱作分路復用協議，
Bayeux的主要目的是支持使用ajax的客戶端與伺服器端之間靈敏，快速的信息交互。
Bayeux 是一種用來在客戶端和伺服器端傳輸低延遲的非同步消息（主要通過http）的一種協議。它定義的消息通過命名通道進行路由並且能夠進行交互傳 送：server - client, client - server 甚至 client - client （當然還是需要通過server中轉）。默認的，此通道已經引用了發布的路由語義，但同時也支持其它路由模塊。
從伺服器端向客戶端非同步發送的數據通常被叫做 「伺服器推」（server-push）。這種使用ajax的web應用和伺服器推技術的結合稱作「Comet」。 Cometd是一個提供多種開發語言的Bayeux項目，由Dojo基金會提供支持。
7、我一多個地面設備通過4G網路向遠程伺服器發送數據採用什麼通信協議
4G網路只是平台，對於你的這個需求來說是透明的，你採用你的協議向遠程伺服器發數據這個操作是在這個4G平台上完成，所以使用什麼協議取決於你的應用。4G網路是承載，不用你考慮的。
8、Android伺服器通信的幾種方式詳解
大 學學習網路基礎的時候老師講過，網路由下往上分為物理層、數據鏈路層、網路層、傳輸層、會話層、表示層和應用層。通過初步的了解，我知道IP協議對應於網 絡層，TCP協議對應於傳輸層，而HTTP協議對應於應用層，三者從本質上來說沒有可比性，socket則是對TCP/IP協議的封裝和應用（程序員層面 上）。也可以說，TPC/IP協議是傳輸層協議，主要解決數據如何在網路中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。關於TCP/IP和 HTTP協議的關系，網路有一段比較容易理解的介紹： 「我們在傳輸數據時，可以只使用（傳輸層）TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別數據內容，如果想要使傳輸的數據有意義，則必須使 用到應用層協議，應用層協議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用層協議。WEB使用HTTP協議作應用層協議，以封裝 HTTP文本信息，然後使用TCP/IP做傳輸層協議將它發到網路上。」
而我們平時說的最多的socket是什麼呢，實際上socket是對TCP/IP協議的封裝，Socket本身並不是協議，而是一個調用介面（API）， 通過Socket，我們才能使用TCP/IP協議。實際上，Socket跟TCP/IP協議沒有必然的聯系。Socket編程介面在設計的時候，就希望也 能適應其他的網路協議。所以說，Socket的出現只是使得程序員更方便地使用TCP/IP協議棧而已，是對TCP/IP協議的抽象，從而形成了我們知道 的一些最基本的函數介面，比如create、listen、connect、accept、send、read和write等等。網路有一段關於 socket和TCP/IP協議關系的說法比較容易理解：「TCP/IP只是一個協議棧，就像操作系統的運行機制一樣，必須要具體實現，同時還要提供對外 的操作介面。這個就像操作系統會提供標準的編程介面，比如win32編程介面一樣，TCP/IP也要提供可供程序員做網路開發所用的介面，這就是 Socket編程介面。」
關於TCP/IP協議的相關只是，用博大精深來講我想也不為過，單單查一下網上關於此類只是的資料和書籍文獻的數量就知道，這個我打算會買一些經典的書籍 （比如《TCP/IP詳解：卷一、卷二、卷三》）進行學習，今天就先總結一些基於基於TCP/IP協議的應用和編程介面的知識，也就是剛才說了很多的 HTTP和Socket。
CSDN上有個比較形象的描述：HTTP是轎車，提供了封裝或者顯示數據的具體形式；Socket是發動機，提供了網路通信的能力。
實際上，傳輸層的TCP是基於網路層的IP協議的，而應用層的HTTP協議又是基於傳輸層的TCP協議的，而Socket本身不算是協議，就像上面所說，它只是提供了一個針對TCP或者UDP編程的介面。
下面是一些經常在筆試或者面試中碰到的重要的概念，特在此做摘抄和總結。
一。什麼是TCP連接的三次握手
第一次握手：客戶端發送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包里不包含數據，三次握手完畢後，客戶端與伺服器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉 連接之前，TCP 連接都將被一直保持下去。斷開連接時伺服器和客戶端均可以主動發起斷開TCP連接的請求，斷開過程需要經過「四次握手」（過程就不細寫了，就是伺服器和客 戶端交互，最終確定斷開）
二。利用Socket建立網路連接的步驟
建立Socket連接至少需要一對套接字，其中一個運行於客戶端，稱為ClientSocket ，另一個運行於伺服器端，稱為ServerSocket 。
套接字之間的連接過程分為三個步驟：伺服器監聽，客戶端請求，連接確認。
1。伺服器監聽：伺服器端套接字並不定位具體的客戶端套接字，而是處於等待連接的狀態，實時監控網路狀態，等待客戶端的連接請求。
2。客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是伺服器端的套接字。為此，客戶端的套接字必須首先描述它要連接的伺服器的套接字，指出伺服器端套接字的地址和埠號，然後就向伺服器端套接字提出連接請求。
3。 連接確認：當伺服器端套接字監聽到或者說接收到客戶端套接字的連接請求時，就響應客戶端套接字的請求，建立一個新的線程，把伺服器端套接字的描述發給客戶 端，一旦客戶端確認了此描述，雙方就正式建立連接。而伺服器端套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連接請求。
三。HTTP鏈接的特點
HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連接。從建立連接到關閉連接的過程稱為「一次連接」。
四。TCP和UDP的區別（考得最多。。快被考爛了我覺得- -\\）
1。 TCP是面向鏈接的，雖然說網路的不安全不穩定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上（實際上也很大程度上保證 了）保證了連接的可靠性；而UDP不是面向連接的，UDP傳送數據前並不與對方建立連接，對接收到的數據也不發送確認信號，發送端不知道數據是否會正確接 收，當然也不用重發，所以說UDP是無連接的、不可靠的一種數據傳輸協議。
2。也正由於1所說的特點，使得UDP的開銷更小數據傳輸速率更高，因為不必進行收發數據的確認，所以UDP的實時性更好。
知 道了TCP和UDP的區別，就不難理解為何採用TCP傳輸協議的MSN比採用UDP的QQ傳輸文件慢了，但並不能說QQ的通信是不安全的，因為程序員可以 手動對UDP的數據收發進行驗證，比如發送方對每個數據包進行編號然後由接收方進行驗證啊什麼的，即使是這樣，UDP因為在底層協議的封裝上沒有採用類似 TCP的「三次握手」而實現了TCP所無法達到的傳輸效率。
9、TCP和UDP網路通訊的區別及實現方式
TCP：Transmission Control Protocol 傳輸控制協議TCP是一種面向連接（連接導向）的、可靠的、基於位元組流的運輸層（Transport layer）通信協議，在 OSI模型中，它完成第四層傳輸層所指定的功能。
UDP：是User Datagram Protocol的簡稱，用戶數據包協議，是 OSI 參考模型中一種無連接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務。
TCP和UDP傳輸就類似於我們的手機通電話和手機發簡訊，一種必需連通了，才能夠通話，相對來說比較可靠，傳輸速度比較快，另一種可以在關機狀態（無連接）發送信息，相對來說，可靠性比較差，傳輸速度較慢。具體的差別如下：
TCP協議面向連接，UDP協議面向非連接
TCP協議傳輸速度慢，UDP協議傳輸速度快
TCP協議保證數據順序，UDP協議不保證
TCP協議保證數據正確性，UDP協議可能丟包
TCP協議對系統資源要求多，UDP協議要求少
不管是基於TCP還是基於UDP的網路通訊編程，都要區分伺服器端和客戶端，下面以TCP為例，實現客戶端和伺服器端通訊的實現步驟：
TCP伺服器端的編寫步驟：
1. 首先，你需要創建一個用於通訊的套介面，一般使用socket調用來實現。這等於你有了一個用於通訊的電話：）
2. 然後，你需要給你的套介面設定埠，相當於，你有了電話號碼。這一步 一般通過設置網路套介面地址和調用bind函數來實現。
3. 調用listen函數使你的套介面成為一個監聽套接字。 以上三個步驟是TCP伺服器的常用步驟。
4. 調用accept函數來啟動你的套接字，這時你的程序就可以等待客戶端的連接了。
5. 處理客戶端的連接請求。
6. 終止連接。
TCP編程的客戶端一般步驟是：
1、創建一個socket，用函數socket()；
2、設置socket屬性，用函數setsockopt();* 可選
3、綁定IP地址、埠等信息到socket上，用函數bind();* 可選
4、設置要連接的對方的IP地址和埠等屬性；
5、連接伺服器，用函數connect()（相當於撥號）；
6、收發數據，用函數send()和recv()，或者read()和write()（相當於通話）;
10、路由器與伺服器之間互相通信的協議
1．「ping」命令所產生的數據包，我們歸類為ICMP協議。說白了就是向目的地發送一個數據包，然後等待回應，如果回應正常則目的地的網路就是通的。當我們輸入了「ping」命令之後，我們的機器（電腦A）就生成了一個包含ICMP協議域的數據包，姑且稱之為「小德」吧~~~~
2．「小德」已經將ICMP協議打包到數據段里了，可是還不能發送，因為一個數據要想向外面傳送，還得經過「有關部門」的批准------IP協議。IP要將你的「寫信人地址」和「收信人地址」寫到數據段上面，即：將數據的源IP地址和目的IP地址分別打包在「小德」的頭部和尾部，這樣一來，大家才知道你的數據是要送到哪裡。
3．准備工作還沒有完。接下來還有部門要審核------ARP。ARP屬於數據鏈路層協議，主要負責把IP地址對應到硬體地址。直接說吧，都怪交換機太「傻」，不能根據IP地址直接找到相應的計算機，只能根據硬體地址來找。於是，交換機就經常保留一張IP地址與硬體地址的對應表以便其查找目的地。而ARP就是用來生成這張表的。比如：當「小德」被送到ARP手裡之後，ARP就要在表裡面查找，看看「小德」的IP地址與交換機的哪個埠對應，然後轉發過去。如果沒找到，則發一個廣播給所有其他的交換機埠，問這是誰的IP地址，如果有人回答，就轉發給它。
4．經過一番折騰，「小德」終於要走出這個倒霉的區域網了。可在此之前，它們還沒忘給「小德」屁股後面蓋個「戳」，說是什麼CRC校驗值，怕「小德」在旅行途中缺胳膊少腿，還得麻煩它們重新發送。。。。。我靠~~~~註：很多人弄不清FCS和CRC。所謂的CRC是一種校驗方法，用來確保數據在傳輸過程中不會丟包，損壞等等，FCS是數據包（准確的說是frame）里的一個區域，用來存放CRC的計算結果的。到了目的地之後，目的計算機要檢查FCS里的CRC值，如果與原來的相同，則說明數據在途中沒有損壞。
5．在走出去之前，那些傢伙最後折磨了一次「小德」------把小德身上眾多的0和1，弄成了什麼「高電壓」「低電壓」，在雙絞線上傳送了出去。暈~~出趟門就這么麻煩嗎？
6．坐著雙絞線旅遊，爽！可當看到很多人坐著同軸電纜，還有坐光纖的時候，小德又感覺不是那麼爽了。就在這時，來到了旅途的中轉站------路由器。這地方可是高級場所，人家直接查看IP地址！剩下的一概不管，交給下面的人去做。夠牛吧？路由器的內部也有一張表，叫做路由表，裡面標識著哪一個網路的IP對應著路由器的哪一個埠。這個表也不是天生就有的，而是靠路由器之間互相「學習」之後生成的，當然也可以由管理員手工設定。這個「學習」的過程是依靠路由協議來完成的，比如RIP，EIGRP，OSPF等等。
7．當路由器查看了「小德」的IP地址以後，根據路由表知道了小德要去的網路，接著就把小德轉到了相應的埠了。至此，路由器的主要工作完成，下面又是打包，封裝成frame，轉換成電壓信號等一系列「折騰」的活，就由數據鏈路層和物理層的模塊去干吧。
8．小德從路由器的出口出來，便來到了目的地----電腦B----所屬的網路的默認網關。默認網關可以是路由器的一個埠，也可以是區域網里的各種伺服器。不管怎樣，下面的過程還是一樣的：到交換機里的ARP表查詢「小德」的IP地址，看看屬於哪個區域網段或埠，然後就轉發到B了。
9．進了B的網卡之後，還要層層「剝皮」，基本上和從A出來的程序是一樣的------電腦B先校驗一下CRC值，看看數據是否完整；然後檢查一下frame的封裝，看到是IP協議之後，就把「小德」交給IP「部門」了；IP協議一看目的地址，正確，再看看應用協議，是ICMP。於是知道了該怎麼做了------產生一個回應數據包，（可以命名為「回應小德」），並准備以同樣的順序向遠端的A發送。。至於剛剛收到的那個數據包就丟棄了。
10．「回應小德」這個數據包又開始了上述同樣的循環，只不過這次發送者是B而接收者是A了。 以上是一個最簡單的路由過程，任何復雜的網路都是在次基礎之上實現的。