網(wǎng)絡(luò)編程知識(shí)

一.網(wǎng)絡(luò)七層模型

OSI模型：

        OSI 模型(Open System Interconnection model)是一個(gè)由國際標(biāo)準(zhǔn)化組織􏰁提出的概念模型，試圖提供一個(gè)使各種不同的計(jì)算機(jī)和網(wǎng)絡(luò)在世界范圍內(nèi)實(shí)現(xiàn)互聯(lián)的標(biāo)準(zhǔn)框架。它將計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)劃分為七層，每層都可以提供抽象良好的接口。了解 OSI 模型有助于理解實(shí)際上互聯(lián)網(wǎng)絡(luò)的工業(yè)標(biāo)準(zhǔn)—— TCP / IP 協(xié)議（族）。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-No810uUq-1690518028857)(C:\Users\xie19\Pictures\Camera Roll\屏幕截圖 2023-07-13 121801.png)]

由上至下，對(duì)七個(gè)層的應(yīng)用做簡單的介紹：

應(yīng)用層：規(guī)定數(shù)據(jù)的傳輸協(xié)議

常見的應(yīng)用層協(xié)議：

協(xié)議	端口	說明
HTTP	80	超文本傳輸協(xié)議
HTTPS	443	HTTP+SSL,HTTP的安全版
FTP	20，21，990	文本傳輸協(xié)議
telnet	23	遠(yuǎn)程終端協(xié)議

表示層：應(yīng)用層數(shù)據(jù)編碼和轉(zhuǎn)化,以確保以一個(gè)系統(tǒng)應(yīng)用層發(fā)送的信息 可以被另一個(gè)系統(tǒng)應(yīng)用層識(shí)別;

EG: 解決不同系統(tǒng)之間的通信,比如Linux下的QQ和Windows下的QQ可以通信

會(huì)話層：

建立一個(gè)連接（自動(dòng)的手機(jī)信息、自動(dòng)的網(wǎng)絡(luò)尋址）

傳輸層：

每一個(gè)應(yīng)用程序都會(huì)在網(wǎng)卡注冊(cè)一個(gè)端口號(hào)，該層就是端口與端口的通信！常用的（TCP／IP）協(xié)議；

網(wǎng)絡(luò)層：

此處需要確定計(jì)算機(jī)的位置，怎么確定？IPv4，IPv6！

網(wǎng)絡(luò)鏈路層

規(guī)定了0和1的分包形式，確定了網(wǎng)絡(luò)數(shù)據(jù)包的形式；

物理層

物理層負(fù)責(zé)最后將信息編碼成電流脈沖或其它信號(hào)用于網(wǎng)上傳輸

下面的圖表顯示了常見的不同的TCP/IP和其他的協(xié)議在最初OSI模型中的位置

協(xié)議	位置
HTTP、FTP、 telnet、 SIP、 SSH	應(yīng)用層
NCP、AFP	表示層
SSH、BSD socket	會(huì)話層
TCP、UDP	傳輸層
IP	網(wǎng)絡(luò)層
以太網(wǎng)	數(shù)據(jù)鏈路層
光纖、無線電	物理層

由于OSI是一個(gè)理想的模型，因此一般網(wǎng)絡(luò)系統(tǒng)只涉及其中的幾層，很少有系統(tǒng)能夠具有所有的7層，并完全遵循它的規(guī)定。

二、三次握手

1.第一次握手

客戶端發(fā)送 SYN 包（ syn = j ）到服務(wù)器，并進(jìn)入 SYN_SEND 狀態(tài)，等待服務(wù)器確認(rèn)。

j 是一個(gè)隨機(jī)數(shù)，通過看服務(wù)器返回的 j + 1 是否正確，判斷第一次握手服務(wù)器是否正確響應(yīng)

2.第二次握手

服務(wù)器確認(rèn)客戶的 SYN 包，同時(shí)發(fā)送 ACK 包（ ack = j + 1 ）作為回應(yīng)；

自己也發(fā)送一個(gè) SYN 包（ syn = k ），共兩個(gè)包，此時(shí)服務(wù)器進(jìn)入 **SYN_RECV**** 狀態(tài)；

k 也是一個(gè)隨機(jī)數(shù)，也是用于看客戶端返回的 k+1 是否正確，判斷第二次握手客戶端是否正確響應(yīng)。

3.第三次握手

客戶端收到服務(wù)器的 SYN＋ACK 包，向服務(wù)器發(fā)送確認(rèn)包 ACK ( ack = k + 1 )，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入 ESTABLISHED 狀態(tài)，完成三次握手。

握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前，TCP 連接都將被一直保持下去。

三、socket，http,TCP

有一篇博文寫的很好

http://t.csdn.cn/N50wA

四、http協(xié)議

1.http協(xié)議得特性

http協(xié)議是建立在TCP/IP協(xié)議之上應(yīng)用層協(xié)議，默認(rèn)端口為80或者8080

http協(xié)議的的特點(diǎn)是無狀態(tài)，短連接

2.http協(xié)議得請(qǐng)求

利用抓包工具h(yuǎn)ttpwatch可以獲取報(bào)文，多見于前端，后端用于分析數(shù)據(jù)傳輸過程中產(chǎn)生的問題 

http協(xié)議的報(bào)文傳輸?shù)氖?strong>ASCII碼，在TCP/IP協(xié)議之上，主要主要分為三部分：

請(qǐng)求行

1.  瀏覽器向服務(wù)器發(fā)送的，在第一行，包含：.請(qǐng)求方式（GET請(qǐng)求、POST請(qǐng)求）.url（網(wǎng)址）.http協(xié)議版本
   

GET請(qǐng)求

例如：

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-p8HwCbBK-1690518028859)(C:\Users\xie19\Pictures\Camera Roll\18902323239.png)]

請(qǐng)求方式是GET請(qǐng)求，url 攜帶的參數(shù)可見，http協(xié)議版本是1.1

POST請(qǐng)求

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-x0qXbmnj-1690518028859)(C:\Users\xie19\Pictures\Camera Roll\555555.png)]

請(qǐng)求方式為POST請(qǐng)求，url攜帶的參數(shù)不可見，協(xié)議版本是1.1

3.POST與GET的區(qū)別

1.本質(zhì)區(qū)別

GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包；POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包。

對(duì)于GET方式的請(qǐng)求，瀏覽器會(huì)把 http header 和 data 一并發(fā)送出去，服務(wù)器響應(yīng)200（返回?cái)?shù)據(jù)）；
對(duì)于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送 data，服務(wù)器響應(yīng)200 ok（返回?cái)?shù)據(jù)）。200，一般以2開頭的為成功，以4開頭是失敗

2.具體區(qū)別

2.1.url的參數(shù)是否可見

get請(qǐng)求：url攜帶的參數(shù)可見

var url = 'http://192.168.1.40:8080/v1/sea?page=1&per_page=10' + 'search=' + escape(str)

post請(qǐng)求：url 攜帶的參數(shù)不可見（參數(shù)被隱藏，可以通過抓包）

2.2參數(shù)傳遞方式

get，通過請(qǐng)求行拼接url進(jìn)行傳遞參數(shù)

post，通過請(qǐng)求主體傳輸參數(shù)

3.緩存性

get 請(qǐng)求是可以緩存的

post 請(qǐng)求不可以緩存

4.頁面后退的反應(yīng)

get 請(qǐng)求頁面后退時(shí)，不產(chǎn)生影響（因?yàn)橛芯彺?#xff09;

post 請(qǐng)求頁面后退時(shí)，會(huì)重新提交請(qǐng)求（沒有緩存）

5.傳輸數(shù)據(jù)的大小

get 一般傳輸數(shù)據(jù)大小不超過2k-4k（根據(jù)瀏覽器不同，限制不一樣，但相差不大）

post 請(qǐng)求傳輸數(shù)據(jù)的大小根據(jù) php.ini 配置文件設(shè)定，也可以無限大

6.安全性

這個(gè)也是最不好分析的，原則上 post 肯定要比 get 安全，畢竟傳輸參數(shù)時(shí) url 不可見，但也擋不住部分人閑的沒事在那抓包玩。安全性個(gè)人覺得是沒多大區(qū)別的，對(duì)傳遞的參數(shù)進(jìn)行加密，其實(shí)都一樣。

7.請(qǐng)求頭

瀏覽器向服務(wù)器發(fā)送一些狀態(tài)數(shù)據(jù)，標(biāo)識(shí)數(shù)據(jù)等等

一個(gè)信息一行，包括信息名：信息值，按行分隔。

User-Agent: firefox//表示發(fā)送請(qǐng)求的瀏覽器（請(qǐng)求代理端）是firefox
Host: shop.100.com//表示請(qǐng)求的主機(jī)域名（基于域名的虛擬主機(jī)就是靠這個(gè)頭判斷的）
Cookie:name=itcast//瀏覽器攜帶的cookie數(shù)據(jù)。
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive

注意，請(qǐng)求頭信息，需要使用一個(gè)空行結(jié)束！

8.請(qǐng)求主體

請(qǐng)求代理端向服務(wù)器端，發(fā)送的請(qǐng)求數(shù)據(jù)！

典型的就是POST形式發(fā)送的表單數(shù)據(jù)！

get請(qǐng)求，沒有請(qǐng)求主體部分！get數(shù)據(jù)是在請(qǐng)求行中的url上進(jìn)行傳遞的！

4.http協(xié)議的響應(yīng)

HTTP/1.1 200 ok
Date: Tue，19 Nov 2013 03:08:55 GMT
Server: Apache/2. 2.22 (Win32) PHP/5.3. 13
X- -Powered -By: PHP/5. 3.13
Content-Length: 16
Content- Type: text/html

響應(yīng)行：

響應(yīng)行包括：協(xié)議版本、狀態(tài)碼、狀態(tài)消息。典型的：

(以1開頭)1xx:消息
(以2開頭)2xx:成功
(以3開頭)3xx:請(qǐng)求被重定向
(以4開頭)4xx:瀏覽器端錯(cuò)誤
(以5開頭)5xx:服務(wù)器端錯(cuò)誤

響應(yīng)頭：

Date：響應(yīng)的時(shí)間。GMT時(shí)間！
Content-Length： 響應(yīng)主體數(shù)據(jù)的長度！
Content-Type: text/html ：內(nèi)容類型:告知瀏覽器接下來發(fā)送的響應(yīng)主體數(shù)據(jù)是什么格式！

響應(yīng)主體：

主要的響應(yīng)數(shù)據(jù)，在瀏覽器的主體區(qū)域顯示的數(shù)據(jù)都是相應(yīng)主體！（前端人員通過html和css技術(shù)實(shí)現(xiàn)的排版，對(duì)于C語言來說拿到的就是一段ASCII碼、一段字符串）

注意，每行，包括響應(yīng)行和響應(yīng)頭，都需要一個(gè) r\n 結(jié)尾

五、HTTPS協(xié)議

1.簡介與原理

http協(xié)議是明文傳輸的，因此很容易被截取和解析，泄漏個(gè)人數(shù)據(jù)。https協(xié)議是在 http 和 tcp 之間多添加了一層加密SSL，進(jìn)行身份驗(yàn)證和數(shù)據(jù)加密。

2、密碼學(xué)基礎(chǔ)

明文與密文

明文： 明文指的是未被加密過的原始數(shù)據(jù)。
密文： 明文被某種加密算法加密之后，會(huì)變成密文，從而確保原始數(shù)據(jù)的安全。密文也可以被解密，得到原始的明文。

密鑰

密鑰：密鑰是一種參數(shù)，它是在明文轉(zhuǎn)換為密文或?qū)⒚芪霓D(zhuǎn)換為明文的算法中輸入的參數(shù)。

? 密鑰分為對(duì)稱密鑰與非對(duì)稱密鑰，分別應(yīng)用在對(duì)稱加密和非對(duì)稱加密上。

對(duì)稱加密(私鑰+私鑰)

*對(duì)稱加密*：對(duì)稱加密又叫做私鑰加密，即信息的發(fā)送方和接收方使用****同一個(gè)密鑰****去加密和解密數(shù)據(jù)。

? 對(duì)稱加密的特點(diǎn)是算法公開、加密和解密速度快，適合于對(duì)大數(shù)據(jù)量進(jìn)行加密，常見的對(duì)稱加密算法有****DES*、3DES、TDEA、Blowfish、*RC5****和IDEA。

其加密過程如下：明文 + 加密算法 + 私鑰 => 密文
解密過程如下    ： 密文 + 解密算法 + 私鑰 => 明文

對(duì)稱加密中用到的密鑰叫做私鑰，私鑰表示個(gè)人私有的密鑰，即該密鑰不能被泄露。

    其加密過程中的私鑰與解密過程中用到的私鑰是同一個(gè)密鑰，這也是稱加密之所以稱之為“對(duì)稱”的原因。

由于對(duì)稱加密的算法是公開的，所以一旦私鑰被泄露，那么密文就很容易被破解，所以對(duì)稱加密的缺點(diǎn)是密鑰安全管理困難。

非對(duì)稱加密(公鑰+私鑰)

*非對(duì)稱加密*：非對(duì)稱加密也叫做公鑰加密。

非對(duì)稱加密使用一對(duì)密鑰，即公鑰和私鑰，且二者成對(duì)出現(xiàn)。私鑰被自己保存，不能對(duì)外泄露。公鑰指的是公共的密鑰，任何人都可以獲得該密鑰。用公鑰或私鑰中的任何一個(gè)進(jìn)行加密，用另一個(gè)進(jìn)行解密。

（1）被公鑰加密過的密文只能被私鑰解密，過程如下：
明文 + 加密算法 + 公鑰 => 密文， 密文 + 解密算法 + 私鑰 => 明文
（2）被私鑰加密過的密文只能被公鑰解密，過程如下：
明文 + 加密算法 + 私鑰 => 密文， 密文 + 解密算法 + 公鑰 => 明文

由于加密和解密使用了兩個(gè)不同的密鑰，這就是非對(duì)稱加密“非對(duì)稱”的原因。

非對(duì)稱加密的缺點(diǎn)是加密和解密花費(fèi)時(shí)間長、速度慢，只適合對(duì)少量數(shù)據(jù)進(jìn)行加密。

在非對(duì)稱加密中使用的主要算法有：*RSA*、Elgamal、Rabin、D-H、ECC（橢圓曲線加密算法）等。

這些算法不用親自去寫，已經(jīng)成為一種標(biāo)準(zhǔn)，有現(xiàn)成的庫去調(diào)用實(shí)現(xiàn)即可。

六.HTTPS相對(duì)于HTTP優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：正確率更高，安全性更強(qiáng)
使用 HTTPS 協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器 ；

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

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

缺點(diǎn)：效率低，成本高
相同網(wǎng)絡(luò)環(huán)境下，HTTPS 協(xié)議會(huì)使頁面的加載時(shí)間延長近 50%，增加 10%到 20%的耗電。

HTTPS 協(xié)議還會(huì)影響緩存，增加數(shù)據(jù)開銷和功耗 。

HTTPS 協(xié)議的安全是有范圍 中間人攻擊 偽造證書

http：安全系數(shù)不高，但是效率高，成本低

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

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

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

缺點(diǎn)：效率低，成本高
相同網(wǎng)絡(luò)環(huán)境下，HTTPS 協(xié)議會(huì)使頁面的加載時(shí)間延長近 50%，增加 10%到 20%的耗電。

HTTPS 協(xié)議還會(huì)影響緩存，增加數(shù)據(jù)開銷和功耗 。

HTTPS 協(xié)議的安全是有范圍 中間人攻擊 偽造證書

http：安全系數(shù)不高，但是效率高，成本低