Linux--網路2(應用層)

目錄

1.HTTP概述

2.HTTP協議的URL解釋

3.HTTP協議的資料流

4.HTTP協議的格式

4.1HTTP請求格式

4.2HTTP回應格式

5.HTTP協議的版本

6.HTTP協議的請求方法

6.1GET方法與POST方法

6.2其他的請求方法

7.HTTP協議的回應狀態碼

7.1狀態碼類別

8.請求/相應的常見欄位

9.代碼模擬實作HTTP協議與瀏覽器的互動

10.子定制協議

10.1TCP粘包的現象

10.2解決TCP粘包的現象

10.3序列化和反序列化

在學習HTTP協議時,我們需要掌握的內容有九個點，

1.HTTP概述

1. HTTP協議，HyperText Transfer Protocol，超文本傳輸協議，
2. HTTP協議是無連接，無狀態，作業在應用層的協議，

在這里解釋一下HTTP協議的兩個特性，無連接，無狀態，

• 無連接指的是HTTP協議本身在發送HTTP資料的時候并不需要與服務端建立連接，這是從HTTP協議本身所說的，但是HTTP協議作為應用層協議，它在傳輸層使用的是TCP協議，TCP在傳輸協議的程序中是要建立連接的，
• 無狀態是指HTTP協議本身是對請求和回應之間的通信狀態不進行保存，現在雙方的狀態是服務端在實作的機制，這個機制我們稱之為會話機制，也就是說在HTTP這個級別，協議對于發送過的請求或回應都不做持久化處理，

2.HTTP協議的URL解釋

• a. 協議方案名：總共分為兩個http與https，兩個都是超文本傳輸協議，只不過https在http上增加了ssl加密程序，ssl是一個非對稱加密，會對http雙方發送的資料進行加密，
• b.登錄資訊：早期時顯示的我們的身份與認證，現在并沒有，因為是不安全的行為，
• c.域名：他最侄訓被DNS協議決議成為IP地址，
• d.服務端的埠號：指定服務器連接的網路埠號，若用戶省略則自動使用默認埠號，
• e.帶層次的檔案路徑：這是向服務端后臺請求的資源，而他之前的'/'指的是服務器當中的邏輯根目錄，而不是Linux服務器的根目錄，服務端可以指定一個路徑為http服務端的根目錄的其實路徑，
• f.查詢字串：他是提交給服務端的資料，在這里要注意，1.他的格式為key=value,如果有多個，則格式為key=value&key1=value1，2.再提交上去的的內容有通俗意義的字串要進行轉碼，將字符采用16進制進行表示，使用%這個字符+urlencode之后的字符來表示，其中%是告訴我們服務端后面的內容是經過urlencode的字符，需要服務端進行解碼，
• g.片段識別符號：現在已經不太常用，使用它通常可以標記出已經湖區資源的子資源(檔案內的某個位置)，

拓展：

非對稱加密分為了公鑰與私鑰，服務端持有私鑰，http客戶端持有公鑰，在HTTP客戶端使用公鑰進行加密，加密完后傳輸到服務端，服務端用私鑰進行解密就可以得到原生的內容，而在網路傳輸程序當中，如果有人進行網路資料的抓取由于他沒有私鑰，他拿到的資料是決議不了的，也就是說即使拿到了資料包也是一堆亂碼，這就完成了對傳輸資料的保密程序，

3.HTTP協議的資料流

左邊我們可以理解為是瀏覽器，右邊可以理解為HTTP的服務端，瀏覽器在這里會先產生一個HTTP資料，HTTP資料就按照HTTP協議格式將它進行封裝并且交給傳輸層；傳輸層得到后在這里打上TCP首部然后遞交給網路層；網路成在這里打上IP協議的包頭后遞交給資料鏈路層；資料鏈路層打上以太網頭部和以太網尾部傳遞給物理層；物理層將這個二進制處理成過電信號在網路當中進行傳輸，傳輸到對端，對端拿到資料之后再將其轉化成二進制和格式，然后層層去掉原生資料的封裝，最后拿到的資料還是按照HTTP協議組織得到的資料，在這里資料流還是牽扯到了兩點，封裝與分用，

4.HTTP協議的格式

HTTP協議規定，請求從客戶端發出，最后服務端回應該請求并回傳，話句話說肯定是先從客戶端開始建立通信的，服務器端在沒有接受到請求之前是不會發送相應，

4.1HTTP請求格式

HTTP的請求格式分為了四個部分：請求首行(方法URI協議版本)，請求體(key:value的屬性行)，空行，請求正文 ，

我們先給出框架，如下圖：

4.2HTTP回應格式

HTTP回應格式有四部分，分別是回應首行(協議首行，狀態碼，狀態碼解釋),回應體，空行和回應內容，

5.HTTP協議的版本

1. HTTP/0.9:HTTP 于 1990 年問世，那時的 HTTP 并沒有作為正式的標準被建?， 現在的 HTTP其實含有 HTTP1.0 之前版本的意思，因此被稱為 HTTP/0.9，
2. HTTP/1.0:HTTP 正式作為標準被公布是在1996 年的 5 ?，版本被命名為 HTTP/1.0，并記載于 RFC1945，雖說是初期標準，但該協議標準?今仍被?泛使?在服務器端，
3. HTTP/1.1:這是目前主流的HTTP協議版本，
4. HTTP/2.0:0 新 ?代HTTP/2.0 正在制訂中，但要達到較?的使?覆寫率，仍需假以時?，

6.HTTP協議的請求方法

請求方法當中比較常見的有Get與Post，

6.1GET方法與POST方法

• Get：向服務端索要某些資源，也可以給服務端提供少量的資料在URL當中(少量的原因是URL的長度是有限制的，所以不能無限制給服務端提交資料在"查詢字串當中"，且URL在不同瀏覽器當中是不同的)，
• Post：給服務器傳輸資源的方法，提交的資料實在請求正文當中傳輸給服務端，
• POST與GET對比：POST方法比GET方法更加私密，不能說POST方法比GET方法更加安全，因為無論GET方法是在URL當中提交資料，還是POST方法在請求正文當中提交資料，都是明文傳輸，

6.2其他的請求方法

• PUT:它用來傳輸檔案，HTTP沒有校驗，一般情況下，后臺的服務端是不支持PUT方法的，
• HEAD:獲取回應頭部，只獲取回應首行和請求體，為了測驗請求資源是否有效，
• DELETE：洗掉檔案，HTTP沒有校驗，一般情況下，后臺的服務端是不支持DELETE方法的，
• OPTIONS：詢問服務端支持的方法，

常見的請求方法的說明，如下表：

7.HTTP協議的回應狀態碼

7.1狀態碼類別

7.2具體的回應狀態碼

• 200：OK，表示從客戶端發來的請求在服務端被正常處理了，
• 302：Found，臨時重定向行為，在服務器當中，資源的URI已經臨時重定向d奧其他位置，
• 404：Not Found，服務器桑沒有請求資源，訪問的頁面不存在，
• 502：Bad Getway，壞的網關

8.請求/相應的常見欄位

• Content-Type:正文的型別（text/html：回傳原生的html頁面; application/json：json資料型別）
• Content-Length:正文的長度
• Host:保存服務端的IP和埠資訊
• User-Agent:保存的是作業系統和瀏覽器版本的資訊
• Location:保存重定向的網頁地址
• Connection:keep-alive，保持長連接(HTTP底層使用到的TCP保持長連接)
• Cookie:他是服務端回傳給瀏覽器的，由瀏覽器進行保存Cookie；在訪問服務器其他界面的時候，由瀏覽器自動在請求體當中加上Cookie，(它的作用：服務端通過Cookie當中的value值，可以得到服務端生成的sessionid，通過會話id，可以在服務端查詢出來是哪一個用戶的session；瀏覽器通過請求當中的Cookie資訊提交到服務端，服務端就可以通過Cookie保存的會話資訊，進行會話校驗)，

9.代碼模擬實作HTTP協議與瀏覽器的互動

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sstream>

using namespace std;

int main(){
    int listen_sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    if(listen_sock < 0){
        perror("socket");
        return 0;
    }

    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_port = htons(28989);
    //0.0.0.0 : 本地所有的網卡地址
    addr.sin_addr.s_addr = inet_addr("0.0.0.0");

    int ret = bind(listen_sock, (struct sockaddr*)&addr, sizeof(addr));
    if(ret < 0){
        perror("bind");
        return 0;
    }

    ret = listen(listen_sock, 1);
    if(ret < 0){
        perror("listen");
        return 0;
    }
    struct sockaddr_in cli_addr;
    socklen_t cli_addrlen = sizeof(cli_addr);
    int newsockfd = accept(listen_sock, (struct sockaddr*)&cli_addr, &cli_addrlen);
    if(newsockfd < 0){
        perror("accept");
        return 0;
    }
    printf("accept new connect from client %s:%d\n", inet_ntoa(cli_addr.sin_addr), ntohs(cli_addr.sin_port));

    while(1){
        //接收
        char buf[1024] = {0};
        ssize_t recv_size = recv(newsockfd, buf, sizeof(buf) - 1, 0);
        if(recv_size < 0){
            perror("recv");
            continue;
        }
        else if(recv_size == 0){
            printf("peer close connect\n");
            close(newsockfd);
            return 0;
        }

        printf("%s\n", buf);
        memset(buf, '\0', sizeof(buf));

        string body = "<html><h1>hello</h1></html>";
        stringstream ss;
        ss << "HTTP/1.1 302 Found\r\n";
        //ss << "Content-Type: text/html\r\n";//相應首行
        //ss << "Content-Length: " << body.size() << "\r\n";//回應體
        ss << "Location: https://www.baidu.com/\r\n";
        ss << "\r\n";
        send(newsockfd, ss.str().c_str(), ss.str().size(), 0);
        send(newsockfd, body.c_str(), body.size(), 0);
    }

    close(listen_sock);
    return 0;
}

10.自定制協議

10.1TCP粘包的現象

我們在了解自定制協議之前先舉個例子：

現在客戶端使用send介面給服務端發送了一串資料給服務端12+12，此時客戶端有發送一條資料24+24，兩條資料依次被丟入網路當中，因為TCP是面向位元組流的，此時兩條資料到達服務端的傳輸層的TCP協議，而此時兩條資料之間沒有任何的分隔符，當應用層呼叫recv介面將資料拿到，但是服務端沒有辦法分析是12+12，24+24還是12+1224+24，此時服務端沒有辦法進行拆分，我們將這種現象稱之為TCP粘包問題，

即就是TCP服務端沒有辦法針對TCP資料進行拆分，拆分成為不同的請求，因為TCP是面向位元組流的，資料之間并沒有明顯的間隔，就導致服務端無法拆分資料，

10.2解決TCP粘包的現象

那么就在應用層自定制我們的協議，用來解決TCP粘包問題，

解決方案：

1. 定義應用層自己的協議資料結構，來描述發送到資料
2. 每一條資料都會友誼和分隔符(\r\n)，來間隔前后兩條資料，

10.3序列化和反序列化

序列化：將物件轉換成二進制資料

反序列化：將二進制資料轉化成物件

舉個栗子：假設在這里有一個結構體

struct a{
    string name;
    string passwd;
};

我們知道這個結構體當中的兩個string物件有可能在我們行程虛擬地址空間中并非連續存盤，而如果不轉化則會發送一些無效的資料，因此將當前的結構體中的物件轉化成連續的二進制資料，這樣就不會傳輸無效的資料，這種方式稱之為序列化，而反序列化就與其相反，

josn也是一個好的使用方式，json是一種key/value的資料結構，可以支持嵌套定義，也可以支持多種基礎型別(int,string,char)，同時也支持將josn物件序列化成二進制序列，也可以將二進制反序列化成josn物件，