HTTP(S)

介紹

HTTP--Hyper Text Transfer Protocol，超文本傳輸協(xié)議，是一種建立在TCP上的無狀態(tài)連接，整個(gè)基本的工作流程是客戶端發(fā)送一個(gè)HTTP請求，說明客戶端想要訪問的資源和請求的動作，服務(wù)端收到請求之后，服務(wù)端開始處理請求，并根據(jù)請求做出相應(yīng)的動作訪問服務(wù)器資源，最后通過發(fā)送HTTP響應(yīng)把結(jié)果返回給客戶端。其中一個(gè)請求的開始到一個(gè)響應(yīng)的結(jié)束稱為事務(wù)，當(dāng)一個(gè)事物結(jié)束后還會在服務(wù)端添加一條日志條目。

HTTP請求

HTTP請求是客戶端往服務(wù)端發(fā)送請求動作，告知服務(wù)器自己的要求。HTTP請求由狀態(tài)行、請求頭、請求正文三部分組成：

狀態(tài)行：包括請求方式Method、資源路徑URL、協(xié)議版本Version；

請求頭：包括一些訪問的域名、用戶代理、Cookie等信息；

請求正文：就是HTTP請求的數(shù)據(jù)。

請求方式Method一般有GET、POST、PUT、DELETE，含義分別是獲取、修改、上傳、刪除，其中GET方式僅僅為獲取服務(wù)器資源，方式較為簡單，因此在請求方式為GET的HTTP請求數(shù)據(jù)中，請求正文部分可以省略，直接將想要獲取的資源添加到URL中。

下圖為POST請求的格式，有狀態(tài)行、請求頭、請求正文三部分：

Post請求.png

HTTP響應(yīng)

響應(yīng)數(shù)據(jù)格式

服務(wù)器收到了客戶端發(fā)來的HTTP請求后，根據(jù)HTTP請求中的動作要求，服務(wù)端做出具體的動作，將結(jié)果回應(yīng)給客戶端，稱為HTTP響應(yīng)。HTTP響應(yīng)由三部分組成：狀態(tài)行、響應(yīng)頭、響應(yīng)正文；

狀態(tài)行：包括協(xié)議版本Version、狀態(tài)碼Status Code、回應(yīng)短語；

響應(yīng)頭：包括搭建服務(wù)器的軟件，發(fā)送響應(yīng)的時(shí)間，回應(yīng)數(shù)據(jù)的格式等信息；

響應(yīng)正文：就是響應(yīng)的具體數(shù)據(jù)。

常見狀態(tài)碼含義

HTTP響應(yīng)模型

服務(wù)器收到HTTP請求之后，會有多種方法響應(yīng)這個(gè)請求，下面是HTTP響應(yīng)的四種模型：

單進(jìn)程I/O模型

服務(wù)端開啟一個(gè)進(jìn)程，一個(gè)進(jìn)程僅能處理一個(gè)請求，并且對請求順序處理；

多進(jìn)程I/O模型

服務(wù)端并行開啟多個(gè)進(jìn)程，同樣的一個(gè)進(jìn)程只能處理一個(gè)請求，這樣服務(wù)端就可以同時(shí)處理多個(gè)請求；

復(fù)用I/O模型

服務(wù)端開啟一個(gè)進(jìn)程，但可以同時(shí)開啟多個(gè)線程，一個(gè)線程響應(yīng)一個(gè)請求，同樣可以達(dá)到同時(shí)處理多個(gè)請求，線程間并發(fā)執(zhí)行；

復(fù)用多線程I/O模型

服務(wù)端并行開啟多個(gè)進(jìn)程，同時(shí)每個(gè)進(jìn)程開啟多個(gè)線程，這樣服務(wù)端可以同時(shí)處理進(jìn)程數(shù)M*每個(gè)進(jìn)程的線程數(shù)N個(gè)請求。

HTTP報(bào)文格式

HTTP報(bào)文是HTTP應(yīng)用程序之間傳輸?shù)臄?shù)據(jù)塊，HTTP報(bào)文分為HTTP請求報(bào)文和HTTP響應(yīng)報(bào)文，但是無論哪種報(bào)文，他的整體格式是類似的，大致都是由起始、首部、主體三部分組成，起始說明報(bào)文的動作，首部說明報(bào)文的屬性，主體則是報(bào)文的數(shù)據(jù)。接下來具體說明。

HTTP請求報(bào)文

請求報(bào)文.png

請求報(bào)文的起始由請求行構(gòu)成（有些資料稱為狀態(tài)行，名字不一樣而已，都是指的一個(gè)東西），用來說明該請求想要做什么，由<Method、<URL、<Version 三個(gè)字段組成，注意每個(gè)字段之間都有一個(gè)空格。其中<Method字段有不同的值：

<URL字段表示服務(wù)器的資源目錄定位

<Version字段表示使用的HTTP協(xié)議版本

首部部分由多個(gè)請求頭(首部行)構(gòu)成，部分首部字段名如下：

主體部分就是報(bào)文的具體數(shù)據(jù)。

HTTP響應(yīng)報(bào)文

響應(yīng)報(bào)文.png

響應(yīng)報(bào)文的起始由狀態(tài)行構(gòu)成，用來說明服務(wù)器做了什么，由<Version、<Status-Code、<Phrase三個(gè)字段組成，同樣的每個(gè)字段之間留有空格；首部由多個(gè)響應(yīng)頭(也叫首部行)組成，部分首部字段名如下：

主體部分是響應(yīng)報(bào)文的具體數(shù)據(jù)。

HTTP協(xié)議版本更替

HTTP/0.9

HTTP協(xié)議的最初版本，功能簡陋，僅支持請求方式GET，并且僅能請求訪問HTML格式的資源。

HTTP/1.0

在0.9版本上做了進(jìn)步，增加了請求方式POST和HEAD；不再局限于0.9版本的HTML格式，根據(jù)Content-Type可以支持多種數(shù)據(jù)格式，即MIME多用途互聯(lián)網(wǎng)郵件擴(kuò)展，例如text/html、image/jpeg等；同時(shí)也開始支持cache，就是當(dāng)客戶端在規(guī)定時(shí)間內(nèi)訪問統(tǒng)一網(wǎng)站，直接訪問cache即可。

但是1.0版本的工作方式是每次TCP連接只能發(fā)送一個(gè)請求，當(dāng)服務(wù)器響應(yīng)后就會關(guān)閉這次連接，下一個(gè)請求需要再次建立TCP連接，就是不支持keep-alive。

HTTP/1.1

解決了1.0版本的keep-alive問題，1.1版本加入了持久連接，一個(gè)TCP連接可以允許多個(gè)HTTP請求； 加入了管道機(jī)制，一個(gè)TCP連接同時(shí)允許多個(gè)請求同時(shí)發(fā)送，增加了并發(fā)性；新增了請求方式PUT、PATCH、DELETE等.

但是還存在一些問題，服務(wù)端是按隊(duì)列順序處理請求的，假如一個(gè)請求處理時(shí)間很長，則會導(dǎo)致后邊的請求無法處理，這樣就造成了隊(duì)頭阻塞的問題；同時(shí)HTTP是無狀態(tài)的連接，因此每次請求都需要添加重復(fù)的字段，降低了帶寬的利用率。

HTTP/2.0

為了解決1.1版本利用率不高的問題，提出了HTTP/2.0版本。增加雙工模式，即不僅客戶端能夠同時(shí)發(fā)送多個(gè)請求，服務(wù)端也能同時(shí)處理多個(gè)請求，解決了隊(duì)頭堵塞的問題；HTTP請求和響應(yīng)中，狀態(tài)行和請求/響應(yīng)頭都是些信息字段，并沒有真正的數(shù)據(jù)，因此在2.0版本中將所有的信息字段建立一張表，為表中的每個(gè)字段建立索引，客戶端和服務(wù)端共同使用這個(gè)表，他們之間就以索引號來表示信息字段，這樣就避免了1.0舊版本的重復(fù)繁瑣的字段，并以壓縮的方式傳輸，提高利用率。另外也增加服務(wù)器推送的功能，即不經(jīng)請求服務(wù)端主動向客戶端發(fā)送數(shù)據(jù)。

當(dāng)前主流的協(xié)議版本還是HTTP/1.1版本。

網(wǎng)絡(luò)訪問量

IP：IP訪問量

相同的公網(wǎng)IP計(jì)算一次，就是同一個(gè)局域網(wǎng)內(nèi)的所有用戶訪問一個(gè)網(wǎng)站，但是他們都是借助一個(gè)公網(wǎng)IP去訪問那個(gè)網(wǎng)站的（NAT），因此這也只能算作一個(gè)IP訪問量。換一次公網(wǎng)IP則會加1。

PV：網(wǎng)頁訪問量

用戶訪問的頁面數(shù)就是PV訪問量，同一個(gè)局域網(wǎng)的不同用戶，而且就算是同一個(gè)用戶，只要刷新一次網(wǎng)站頁面，PV訪問量就加1，三個(gè)訪問量的值往往數(shù)PV的值最大。

UV：訪客訪問量

這里的訪客不是用戶，而是電腦，一臺電腦算一個(gè)訪客，即使是同一臺電腦的不同用戶，訪問同一個(gè)網(wǎng)站UV也只能加1，只有更換電腦才會使UV加1，因?yàn)榉?wù)端會記錄客戶端電腦的信息。

HTTPS

介紹

HTTPS是以安全為目標(biāo)的HTTP通道，是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。HTTPS協(xié)議的主要作用可以分為兩種：一種是建立一個(gè)信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩涣硪环N就是確認(rèn)網(wǎng)站的真實(shí)性。

HTTP與HTTPS的區(qū)別

1.HTTPS協(xié)議需要到ca申請證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。

2.HTTP是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS則是具有安全性的SSL加密傳輸協(xié)議。

3.HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

4.HTTP的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比HTTP協(xié)議安全。

HTTPS的工作原理

HTTPS工作原理.png

客戶端在使用HTTPS方式與Web服務(wù)器通信時(shí)有以下幾個(gè)步驟：

1.客戶使用HTTPS的URL訪問Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。

2.Web服務(wù)器收到客戶端請求后，會將網(wǎng)站的證書信息（證書中包含公鑰）傳送一份給客戶端。

3.客戶端的瀏覽器與Web服務(wù)器開始協(xié)商SSL連接的安全等級，也就是信息加密的等級。

4.客戶端的瀏覽器根據(jù)雙方同意的安全等級，建立會話密鑰，然后利用網(wǎng)站的公鑰將會話密鑰加密，并傳送給網(wǎng)站。

5.Web服務(wù)器利用自己的私鑰解密出會話密鑰。

6.Web服務(wù)器利用會話密鑰加密與客戶端之間的通信。

HTTPS的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

1.使用HTTPS協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；

2.HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。

3.HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。

4.谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS加密的網(wǎng)站在搜索結(jié)果中的排名將會更高”。

缺點(diǎn)

1.HTTPS協(xié)議握手階段比較費(fèi)時(shí)，會使頁面的加載時(shí)間延長近50%，增加10%到20%的耗電；

2.HTTPS連接緩存不如HTTP高效，會增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會因此而受到影響；

3.SSL證書需要錢，功能越強(qiáng)大的證書費(fèi)用越高，個(gè)人網(wǎng)站、小網(wǎng)站沒有必要一般不會用。

4.SSL證書通常需要綁定IP，不能在同一IP上綁定多個(gè)域名，IPv4資源不可能支撐這個(gè)消耗。

5.HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。最關(guān)鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。

Socket

介紹

Socket是應(yīng)用層與TCP/IP協(xié)議族通信的中間軟件抽象層，它是一組接口。在設(shè)計(jì)模式中，Socket其實(shí)就是一個(gè)門面模式，它把復(fù)雜的TCP/IP協(xié)議族隱藏在Socket接口后面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數(shù)據(jù)，以符合指定的協(xié)議。

圖解

Socket圖解.png

通信步驟

Socket通信步驟.png

例子

client

public class Client {

    public static void main(String[] args) throws Exception {
        ServerSocket server_socket = new ServerSocket(8080);
        Socket socket = server_socket.accept();
        InputStream inputStream = socket.getInputStream();
        BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream));
        String str;
        while ((str = reader.readLine()) != null) {
            System.out.println("我是服務(wù)端，我收到的消息是：" + str);
        }
        //用完關(guān)閉
        reader.close();
        inputStream.close();
        socket.close();
        server_socket.close();

    }
}

server

public class Server {

    public static void main(String[] args) throws Exception{
        Socket server_socket = new Socket("127.0.0.1",8080);
        BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(server_socket.getOutputStream()));
        writer.write("你好，jimyoungwei ，這里是客戶端給你發(fā)的消息。");
        writer.flush();
        writer.close();
        server_socket.close();
    }
}

先運(yùn)行client，再運(yùn)行server，運(yùn)行結(jié)果：

/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin/java "-javaagent:/Applications/IntelliJ IDEA CE.app/Contents/lib/idea_rt.jar=62225:/Applications/IntelliJ IDEA CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath /Users/jimyoungwei/IdeaProjects/SocketTest/out/production/SocketTest com.jimyoungwei.Client
我是服務(wù)端，我收到的消息是：你好，jimyoungwei ，這里是客戶端給你發(fā)的消息。

Process finished with exit code 0

TCP/UDP

基本認(rèn)知

TCP和UDP是OSI模型中的運(yùn)輸層中的協(xié)議。TCP提供可靠的通信傳輸，而UDP則常被用于讓廣播和細(xì)節(jié)控制交給應(yīng)用的通信傳輸。

TCP(Transmission Control Protocol，傳輸控制協(xié)議):

連接三次握手：

TCP三次握手.png

第一次握手：Client將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個(gè)值seq=J，并將該數(shù)據(jù)包發(fā)送給Server，Client進(jìn)入SYN_SENT狀態(tài)，等待Server確認(rèn)。

第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請求建立連接，Server將標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機(jī)產(chǎn)生一個(gè)值seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請求，Server進(jìn)入SYN_RCVD狀態(tài)。

第三次握手：Client收到確認(rèn)后，檢查ack是否為J+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了。

斷開四次分手：

TCP四次分手.png

第一次揮手：Client發(fā)送一個(gè)FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進(jìn)入FIN_WAIT_1狀態(tài)。

第二次揮手：Server收到FIN后，發(fā)送一個(gè)ACK給Client，確認(rèn)序號為收到序號+1（與SYN相同，一個(gè)FIN占用一個(gè)序號），Server進(jìn)入CLOSE_WAIT狀態(tài)。

第三次揮手：Server發(fā)送一個(gè)FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入LAST_ACK狀態(tài)。

第四次揮手：Client收到FIN后，Client進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個(gè)ACK給Server，確認(rèn)序號為收到序號+1，Server進(jìn)入CLOSED狀態(tài)，完成四次揮手。

名詞解析：

ACK ：TCP報(bào)頭的控制位之一,對數(shù)據(jù)進(jìn)行確認(rèn).確認(rèn)由目的端發(fā)出,用它來告訴發(fā)送端這個(gè)序列號之前的數(shù)據(jù)段都收到了.比如,確認(rèn)號為X,則表示前X-1個(gè)數(shù)據(jù)段都收到了,只有當(dāng)ACK=1時(shí),確認(rèn)號才有效,當(dāng)ACK=0時(shí),確認(rèn)號無效,這時(shí)會要求重傳數(shù)據(jù),保證數(shù)據(jù)的完整性。

SYN ： 同步序列號,TCP建立連接時(shí)將這個(gè)位置設(shè)置為1。

FIN ：發(fā)送端完成發(fā)送任務(wù)后,當(dāng)TCP完成數(shù)據(jù)傳輸需要斷開時(shí),提出斷開連接的一方將其設(shè)置為1。

包頭結(jié)構(gòu)：

源端口 16位
目標(biāo)端口 16位
序列號 32位
回應(yīng)序號 32位
TCP頭長度 4位
reserved 6位
控制代碼 6位
窗口大小 16位
偏移量 16位
校驗(yàn)和 16位
選項(xiàng) 32位(可選)
這樣我們得出了TCP包頭的最小長度，為20字節(jié)

UDP(User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議):

特點(diǎn)：

1.UDP是一個(gè)非連接的協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接，當(dāng)它想傳送時(shí)就簡單地去抓取來自應(yīng)用程序的數(shù)據(jù)，并盡可能快地把它扔到網(wǎng)絡(luò)上。在發(fā)送端，UDP傳送數(shù)據(jù)的速度僅僅是受應(yīng)用程序生成數(shù)據(jù)的速度、計(jì)算機(jī)的能力和傳輸帶寬的限制；在接收端，UDP把每個(gè)消息段放在隊(duì)列中，應(yīng)用程序每次從隊(duì)列中讀一個(gè)消息段。

2.由于傳輸數(shù)據(jù)不建立連接，因此也就不需要維護(hù)連接狀態(tài)，包括收發(fā)狀態(tài)等，因此一臺服務(wù)機(jī)可同時(shí)向多個(gè)客戶機(jī)傳輸相同的消息。

3.UDP信息包的標(biāo)題很短，只有8個(gè)字節(jié)，相對于TCP的20個(gè)字節(jié)信息包的額外開銷很小。

4.吞吐量不受擁擠控制算法的調(diào)節(jié)，只受應(yīng)用軟件生成數(shù)據(jù)的速率、傳輸帶寬、源端和終端主機(jī)性能的限制。

5.UDP使用盡最大努力交付，即不保證可靠交付，因此主機(jī)不需要維持復(fù)雜的鏈接狀態(tài)表（這里面有許多參數(shù)）。

6.UDP是面向報(bào)文的。發(fā)送方的UDP對應(yīng)用程序交下來的報(bào)文，在添加首部后就向下交付給IP層。既不拆分，也不合并，而是保留這些報(bào)文的邊界，因此，應(yīng)用程序需要選擇合適的報(bào)文大小。

使用“ping”命令來測試兩臺主機(jī)之間TCP/IP通信是否正常，其實(shí)“ping”命令的原理就是向?qū)Ψ街鳈C(jī)發(fā)送UDP數(shù)據(jù)包，然后對方主機(jī)確認(rèn)收到數(shù)據(jù)包，如果數(shù)據(jù)包是否到達(dá)的消息及時(shí)反饋回來，那么網(wǎng)絡(luò)就是通的。

包頭結(jié)構(gòu)：

源端口 16位
目的端口 16位
長度 16位
校驗(yàn)和 16位

優(yōu)點(diǎn)

TCP:

可靠，穩(wěn)定 TCP的可靠體現(xiàn)在TCP在傳遞數(shù)據(jù)之前，會有三次握手來建立連接，而且在數(shù)據(jù)傳遞時(shí)，有確認(rèn)、窗口、重傳、擁塞控制機(jī)制，在數(shù)據(jù)傳完后，還會斷開連接用來節(jié)約系統(tǒng)資源。

UDP:

快，比TCP稍安全 UDP沒有TCP的握手、確認(rèn)、窗口、重傳、擁塞控制等機(jī)制，UDP是一個(gè)無狀態(tài)的傳輸協(xié)議，所以它在傳遞數(shù)據(jù)時(shí)非?？?。沒有TCP的這些機(jī)制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊。

缺點(diǎn)

TCP:

慢，效率低，占用系統(tǒng)資源高，易被攻擊 。TCP在傳遞數(shù)據(jù)之前，要先建連接，這會消耗時(shí)間，而且在數(shù)據(jù)傳遞時(shí)，確認(rèn)機(jī)制、重傳機(jī)制、擁塞控制機(jī)制等都會消耗大量的時(shí)間，而且要在每臺設(shè)備上維護(hù)所有的傳輸連接，事實(shí)上，每個(gè)連接都會占用系統(tǒng)的CPU、內(nèi)存等硬件資源。 而且，因?yàn)門CP有確認(rèn)機(jī)制、三次握手機(jī)制，這些也導(dǎo)致TCP容易被人利用，實(shí)現(xiàn)DOS、DDOS、CC等攻擊。

UDP:

不可靠，不穩(wěn)定。 因?yàn)閁DP沒有TCP那些可靠的機(jī)制，在數(shù)據(jù)傳遞時(shí)，如果網(wǎng)絡(luò)質(zhì)量不好，就會很容易丟包。

應(yīng)用場景

TCP:

當(dāng)對網(wǎng)絡(luò)通訊質(zhì)量有要求的時(shí)候，比如：整個(gè)數(shù)據(jù)要準(zhǔn)確無誤的傳遞給對方，這往往用于一些要求可靠的應(yīng)用，比如HTTP、HTTPS、FTP等傳輸文件的協(xié)議，POP、SMTP等郵件傳輸?shù)膮f(xié)議。 在日常生活中，常見使用TCP協(xié)議的應(yīng)用如下： 瀏覽器用的HTTP FlashFXP，用的FTP Outlook、用的POP、SMTP Putty，用的Telnet、SSH QQ文件傳輸 ……

UDP:

面向數(shù)據(jù)報(bào)方式，網(wǎng)絡(luò)數(shù)據(jù)大多為短消息，擁有大量Client，對數(shù)據(jù)安全性無特殊要求，網(wǎng)絡(luò)負(fù)擔(dān)非常重，但對響應(yīng)速度要求高，這時(shí)就可以使用UDP。 比如，日常生活中，常見使用UDP協(xié)議的應(yīng)用如下： QQ語音 、QQ視頻 、TFTP ……

網(wǎng)絡(luò)編程

具體編程時(shí)區(qū)別：

1.socket()的參數(shù)不同。

2.UDP Server不需要調(diào)用listen和accept 。

3.UDP收發(fā)數(shù)據(jù)用sendto/recvfrom函數(shù) 。

4.TCP：地址信息在connect/accept時(shí)確定 。

5.UDP：在sendto/recvfrom函數(shù)中每次均 需指定地址信息 。

6.UDP：shutdown函數(shù)無效。

服務(wù)器端編程一般步驟：

TCP:

1、創(chuàng)建一個(gè)socket，用函數(shù)socket()。

2、設(shè)置socket屬性，用函數(shù)setsockopt(); * 可選 。

3、綁定IP地址、端口等信息到socket上，用函數(shù)bind()。

4、開啟監(jiān)聽，用函數(shù)listen()。

5、接收客戶端上來的連接，用函數(shù)accept()。

6、收發(fā)數(shù)據(jù)，用函數(shù)send()和recv()，或者read()和write()。

7、關(guān)閉網(wǎng)絡(luò)連接。

8、關(guān)閉監(jiān)聽。

UDP:

1、創(chuàng)建一個(gè)socket，用函數(shù)socket()。

2、設(shè)置socket屬性，用函數(shù)setsockopt();* 可選 。

3、綁定IP地址、端口等信息到socket上，用函數(shù)bind()。

4、循環(huán)接收數(shù)據(jù)，用函數(shù)recvfrom()。

5、關(guān)閉網(wǎng)絡(luò)連接。

客戶端編程一般步驟：

TCP:

1、創(chuàng)建一個(gè)socket，用函數(shù)socket()。

2、設(shè)置socket屬性，用函數(shù)setsockopt();* 可選 。

3、綁定IP地址、端口等信息到socket上，用函數(shù)bind();* 可選 。

4、設(shè)置要連接的對方的IP地址和端口等屬性。

5、連接服務(wù)器，用函數(shù)connect()。

6、收發(fā)數(shù)據(jù)，用函數(shù)send()和recv()，或者read()和write()。

7、關(guān)閉網(wǎng)絡(luò)連接。

UDP:

1、創(chuàng)建一個(gè)socket，用函數(shù)socket()。

2、設(shè)置socket屬性，用函數(shù)setsockopt();* 可選 。

3、綁定IP地址、端口等信息到socket上，用函數(shù)bind();* 可選 。

4、設(shè)置對方的IP地址和端口等屬性。

5、發(fā)送數(shù)據(jù)，用函數(shù)sendto()。

6、關(guān)閉網(wǎng)絡(luò)連接。

區(qū)別

1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。

2、TCP提供可靠的服務(wù)。通過TCP連接傳送的數(shù)據(jù)，無差錯(cuò)，不丟失，不重復(fù)，且按序到達(dá);UDP盡最大努力交付，即不保證可靠交付。

3、TCP面向字節(jié)流，實(shí)際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;UDP是面向報(bào)文的。UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機(jī)的發(fā)送速率降低（對實(shí)時(shí)應(yīng)用很有用，如IP電話，實(shí)時(shí)視頻會議等）。

4、每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對一，一對多，多對一和多對多的交互通信。

5、TCP首部開銷20字節(jié);UDP的首部開銷小，只有8個(gè)字節(jié)。

6、TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道。

上一篇：Android基礎(chǔ)(9)—多線程和異步任務(wù)
下一篇：Android基礎(chǔ)(11)—你需要知道的內(nèi)存知識

精彩內(nèi)容不夠看？更多精彩內(nèi)容，請到微信搜索 “危君子頻道” 訂閱號，每周更新，歡迎大家關(guān)注訂閱！

微信公眾號