Python網絡編程概述

網絡中的術語解釋

名稱 解釋 那一層 說明
端口號 程序地址 傳輸層 區分同一計算機中不同的程序
IP地址 主機地址 網絡層 識別不同的主機或者路由器
MAC地址 物理地址 數據鏈路層 在同一數據鏈路中識別不同的計算機
TCP 基于字節流協議 傳輸層 面向連接,可靠的基于字節流,有順序的協議
UDP 基于數據報協議 傳輸層 面向非連接,不可靠的基于數據報的,無順序的協議
HTTP 基于TCP的協議 應用層 超文本傳輸協議,基于TCP,需要建立連接

TCP和UDP的區別

是否連接:

TCP面向連接(發送數據之前需要建立連接,三次握手).UDP面向無連接的(發送數據無需先建立連接)

是否丟包重試

TCP實現了數據傳輸時的各種控制功能,可以進行丟包的重發機制,還可以對次序亂掉的分包進行順序控制.
因此TCP傳輸的數據是可靠的.UDP不會進行丟包重試,也不會糾正到達的順序,甚至發送之后,根本不關心對象有沒有收到.它是不可靠的,不安全的.

傳輸模式

TCP采用的是流模式(面向字節流) UDP采用的是數據報模式(面向的是報文)

傳輸時兩端的對應關系

TCP是一對一的關系,而UDP傳輸支持一對一,一對多,多對一,多對多的交互

可靠性

TCP全雙工非常可靠,無差錯,不丟失,且按序到達. UDP不保證可靠性,不保證順序到達.

傳輸速度

TCP較慢,UDP叫較快

應用場合

TCP適用于對效率要求不高,但是對準確性要求相對高.或者是要求有連接的狀況.
UDP適用于對效率要求較高,對準確性要求相對較低的場景.

應用示例

TCP一般應用于文件傳輸(HTTP,FTP,對數據的準確性要求較高,速度可以相對較慢)
發送和接收郵件(pop imap SMTP),遠程登錄(telnet SSH 對數據準確性有一定要求,有連接概念)
UDP一般應用于即時通信(QQ聊天) 在線視頻,網絡語音電話

面向連接和非面向連接的形象舉例

面向連接的舉例: 兩個人打電話,首先是撥號對面應答之后才可以通信.
面向非連接的舉例: 發送短信,只管發送,對面接收沒有接收到,并不知道.

OSI七層模型

這里我們只對OSI各層進行功能上的大概闡述,不詳細深究,因為每一層實際都是一個復雜的層。后面我也會根據個人方向展開部分層的深入學習。這里我們就大概了解一下。我們從最頂層——應用層 開始介紹。整個過程以公司A和公司B的一次商業報價單發送為例子進行講解。

應用層

OSI參考模型中最靠近用戶的一層,是為計算機用戶提供應用接口,也為用戶直接提供各種網絡服務。我們常見應用層的網絡服務協議有:HTTP,HTTPS,FTP,POP3、SMTP
實際公司A的老板就是我們所述的用戶,而他要發送的商業報價單,就是應用層提供的一種網絡服務,當然,老板也可以選擇其他服務,比如說,發一份商業合同,發一份詢價單,等等。

表示
表示層提供各種用于應用層數據的編碼和轉換功能,確保一個系統的應用層發送的數據能被另一個系統的應用層識別。如果必要,該層可提供一種標準表示形式,用于將計算機內部的多種數據格式轉換成通信中采用的標準表示形式。數據壓縮和加密也是表示層可提供的轉換功能
由于公司A和公司B是不同國家的公司,他們之間的商定統一用英語作為交流的語言,所以此時表示層(公司的文秘),就是將應用層的傳遞信息轉翻譯成英語。同時為了防止別的公司看到,公司A的人也會對這份報價單做一些加密的處理。這就是表示的作用,將應用層的數據轉換翻譯等。

會話

會話層就是負責建立、管理和終止表示層實體之間的通信會話。該層的通信由不同設備中的應用程序之間的服務請求和響應
會話層的同事拿到表示層的同事轉換后資料,(會話層的同事類似公司的外聯部),會話層的同事那里可能會掌握本公司與其他好多公司的聯系方式,這里公司就是實際傳遞過程中的實體。他們要管理本公司與外界好多公司的聯系會話。當接收到表示層的數據后,會話層將會建立并記錄本次會話,他首先要找到公司B的地址信息,然后將整份資料放進信封,并寫上地址和聯系方式。準備將資料寄出。等到確定公司B接收到此份報價單后,此次會話就算結束了,外聯部的同事就會終止此次會話。

傳輸

傳輸層建立了主機端到端的鏈接,傳輸層的作用是為上層協議提供端到端的可靠和透明的數據傳輸服務,包括處理差錯控制和流量控制等問題。該層向高層屏蔽了下層數據通信的細節,使高層用戶看到的只是在兩個傳輸實體間的一條主機到主機的、可由用戶控制和設定的、可靠的數據通路。我們通常說的,TCP UDP就是在這一層。端口號既是這里的“傳輸層就相當于公司中的負責快遞郵件收發的人,公司自己的投遞員,他們負責將上一層的要寄出的資料投遞到快遞公司或郵局。

網絡

本層通過IP尋址來建立兩個節點之間的連接,為源端的運輸層送來的分組,選擇合適的路由和交換節點,正確無誤地按照地址傳送給目的端的運輸層。就是通常說的IP層。這一層就是我們經常說的IP協議層。IP協議是Internet的
網絡層就相當于快遞公司龐大的快遞網絡,全國不同的集散中心,比如說,從深圳發往北京的順豐快遞(陸運為例啊,空運好像直接就飛到北京了),首先要到順豐的深圳集散中心,從深圳集散中心再送到武漢集散中心,從武漢集散中心再寄到北京順義集散中心。這個每個集散中心,就相當于網絡中的一個IP節點。

數據鏈路

將比特組合成字節,再將字節組合成幀,使用鏈路層地址 (以太網使用MAC地址)來訪問介質,并進行差錯
數據鏈路層又分為2個子層:邏輯鏈路控制子層(LLC)和媒體訪問控制子層(MAC子層處理CSMA/CD算法、數據出錯校驗、成幀等;LLC子層定義了一些字段使上次協議能共享數據鏈路層。 在實際使用中,LLC子層并非必需的。

物理層

實際最終信號的傳輸是通過物理層實現的。通過物理介質傳輸比特流。規定了電平、速度和電纜針腳。常用設備有(各種物理設備)集線器、中繼器、調制解調器、網線、雙絞線、同軸電纜。這些都是物理層的傳輸快遞寄送過程中的交通工具,就相當于我們的物理層,例如汽車,火車,飛機,船。

TCP/IP 五層模型

網絡編程開始之 網絡基礎

問題1? 網絡上一個程序如何精準的找到另一個程序?

首先程序必須先啟動,其次必須要有這臺機器的地址,以及要連接的應用程序的主機的地址.而在計算機的應用程序中我們可以通過ip地址來標識臺主機的地址,而如何確定是哪一個應用程序呢?這個時候就要引入一個端口號的概念,所謂端口號,就是用于區分一臺計算機中不同應用程序的標識。

IP地址是指互聯網協議地址(英語:Internet Protocol Address,又譯為網際協議地址),
是IP Address的縮寫。IP地址是IP協議提供的一種統一的地址格式,
它為互聯網上的每一個網絡和每一臺主機分配一個邏輯地址,以此來屏蔽物理地址的差異。

IP地址是一個32位的二進制數,通常被分割為4個“8位二進制數”(也就是4個字節)。
IP地址通常用“點分十進制”表示成(a.b.c.d)的形式,其中,a,b,c,d都是0~255之間的十進制整數。
例:點分十進IP地址(100.4.5.6),實際上是32位二進制數(01100100.00000100.00000101.00000110)。

總結:通過IP地址我們可以找到通信的是哪一個主機,而通過端口號,我們可以找到具體的主機上的是哪一個應用程序。網絡中標識一個進程的方式:IP + 傳輸層協議 + 端口號

問題2? 什么是socket?

socket層

描述

socket是在應用層和傳輸層之間的一個抽象層,它把TCP/IP層復雜的操作抽象為幾個簡單的接口供應用層調用已實現進程在網絡中通信。

Socket是應用層與TCP/IP協議族通信的中間軟件抽象層,它是一組接口。在設計模式中,Socket其實就是一個門面模式,它把復雜的TCP/IP協議族隱藏在Socket接口后面,對用戶來說,一組簡單的接口就是全部,讓Socket去組織數據,以符合指定的協議。

其實站在你的角度上看,socket就是一個模塊。我們通過調用模塊中已經實現的方法建立兩個進程之間的連接和通信。
也有人將socket說成ip+port,因為ip是用來標識互聯網中的一臺主機的位置,而port是用來標識這臺機器上的一個應用程序。所以我們只要確立了ip和port就能找到一個應用程序,并且使用socket模塊來與之通信。

TCP/UDP

TCP(Transmission Control Protocol 傳輸控制協議) 可靠的,面向連接的協議(eg:打電話),傳輸效率低但是是全雙工一對一的,面向字節流的協議.使用TCP的應用:Web瀏覽器,電子郵件,文件傳輸程序.

UDP(User Datagram Protocal 用戶數據報協議)不可靠的,非面向連接的協議,傳輸效率高,可以一對一,一對多,多對一,多對多,面向報文的協議.使用UDP的應用:域名系統(DNS),視頻流,IP語音

TCP/UDP的編程流程

套接字(socket的使用)

基于TCP協議的socket

server端

# encoding:utf-8
__author__ = 'Fioman'
__date__ = '2018/11/22 10:34'
import socket

# 1.創建套接字,默認是TCP
sk = socket.socket()
# 解決端口一直被占用的情況
sk.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
# 2.綁定地址
sk.bind(("127.0.0.1",9999))
# 3.設置監聽
sk.listen()
# 4.等待連接
conn,addr = sk.accept()
# 5.連接成功,接收數據
ret = conn.recv(4096)
print(ret) # 帶你
# 6.發送數據
conn.send(b'Receive Successful!')

# 7關閉套接字連接
conn.close()  # 關閉和客戶端之間連接的套接字
sk.close() # 關閉服務器套接字

客戶端

# encoding:utf-8
__author__ = 'Fioman'
__date__ = '2018/11/22 10:39'
import socket

# 創建套接字
sk = socket.socket()
# 建立連接
sk.connect(("127.0.0.1", 9999))
# 發送數據
sk.send(b'123')
# 接收響應數據
ret = sk.recv(4096)
print(ret)
# 關閉連接
sk.close()

基于UDP的socket

服務端

# encoding:utf-8
__author__ = 'Fioman'
__date__ = '2018/11/22 10:45'
import socket

# 1.創建一個UDP服務器的套接字,默認是TCP的,所以要傳遞參數type
sk = socket.socket(socket.AF_INET, type=socket.SOCK_DGRAM)

# 2.綁定地址
sk.bind(("127.0.0.1", 8888))
# 3.接收消息
msg, addr = sk.recvfrom(4096)
# 4.發送消息
sk.sendto(b'123', addr)
# 5.關閉服務器套接字
sk.close()

客戶端

# encoding:utf-8
__author__ = 'Fioman'
__date__ = '2018/11/22 10:52'
import socket

# 1.創建socket
sk = socket.socket(type=socket.SOCK_DGRAM)
# 2.發送數據
sk.sendto(b'hello', ('127.0.0.1', 8888))
# 3.接收響應數據
msg, addr = ret = sk.recvfrom(1024)
print(msg.decode('utf-8'), addr)
# 4.關閉連接
sk.close()

TCP協議的粘包

粘包是什么

TCP粘包產生的原因大體上可以分為兩方面:
發送端:

發送端要等待緩沖區滿才發送出去,造成粘包

接收

接收方不及時接收緩沖區的包,造成多個包接收.

TCP粘包主要從以下幾個方面去分析:
1. 發送端: TCP連接是面向流的,使用了Nagle算法進行數據的發送優化
2. 接收端:TCP接收端,接收端的從緩沖區取出數據,取出的數據可以是發送端的多個包的組合.

TCP發送端的Nagle算法

TCP是面向連接的,所以TCP的socket編程,需要收發兩端(客戶端和服務器)都要有成對的socket,因此發送端
為了將多個發送接收端的包,更有效的發送給對方,使用了優化算法(Nagle算法),將多次間隔較小,數量較小的數據,合并成一個大的數據段,進行封包,這樣接收端就不難于分辨出來了.因為是流式的字節流數據,沒有消息邊界.
這是發送端所產生的粘包.

保護消息邊界和流

  • 什么是保護消息邊界?

保護消息邊界,就是指傳輸協議把數據當做一條獨立的消息在網上傳輸,接收端只能接收獨立的消息.也就是說存在保護消息邊界,接收端一次只能接收發送端的發出的一個數據包.而TCP是面向流的傳輸,所以是沒有保護消息邊界的,如果發送端連續發送數據,接收端可能在一次接收中,接收了多個數據包,這樣就可以能因為區分不了數據包的邊界,而造成粘包.

而UDP之所以不會產生粘包,就是因為UDP是面向數據包傳輸的,它是由消息邊界的.UDP的每一個消息都是獨立的.UDP,由于是面向消息傳輸,它把所有接收到的消息都掛接到緩沖區的接收隊列中,因此,它對于數據的提取分離更加的方便.UDP的發送和接收保證了,只要發送一次就會接收一次的原理,即使將多個包發送到緩存區,在接收區,也不會一次取出來,也是要經過相應次數的接收才能將數據取出來.

總結:粘包出現的原因

簡單得說,在流傳輸中出現,UDP不會出現粘包,因為它有消息邊界(參考Windows網絡編程)

1發送端需要等緩沖區滿才發送出去,造成粘包

2接收方不及時接收緩沖區的包,造成多個包接收

具體點:

(1)發送方引起的粘包是由TCP協議本身造成的,TCP為提高傳輸效率,發送方往往要收集到足夠多的數據后才發送一包數據。若連續幾次發送的數據都很少,通常TCP會根據優化算法把這些數據合成一包后一次發送出去,這樣接收方就收到了粘包數據。

(2)接收方引起的粘包是由于接收方用戶進程不及時接收數據,從而導致粘包現象。這是因為接收方先把收到的數據放在系統接收緩沖區,用戶進程從該緩沖區取數據,若下一包數據到達時前一包數據尚未被用戶進程取走,則下一包數據放到系統接收緩沖區時就接到前一包數據之后,而用戶進程根據預先設定的緩沖區大小從系統接收緩沖區取數據,這樣就一次取到了多包數據。

粘包情況有兩種,一種是粘在一起的包都是完整的數據包,另一種情況是粘在一起的包有不完整的包。

不是所有的粘包現象都需要處理,若傳輸的數據為不帶結構的連續流數據(如文件傳輸),則不必把粘連的包分開(簡稱分包)。但在實際工程應用中,傳輸的數據一般為帶結構的數據,這時就需要做分包處理。

在處理定長結構數據的粘包問題時,分包算法比較簡單;在處理不定長結構數據的粘包問題時,分包算法就比較復雜。特別是粘在一起的包有不完整的包的粘包情況,由于一包數據內容被分在了兩個連續的接收包中,處理起來難度較大。實際工程應用中應盡量避免出現粘包現象。

避免粘包的措施

  1. 對于發送方引起的粘包現象,用戶可以通過編程設置來避免,TCP提供了數據立即傳輸,而不使用優化到緩沖區的方法push.
    2)對于接受方引起的粘包,則可以通過程序優化程序設計,提高進程接收優先級,使其及時接收數據,避免產生粘包.

TCP無消息邊界的解決方法

1. 發送固定長度的消息.比如我們發送的時候,可以規定我們消息的長度,這樣接收端就知道要接收多少數據了
2.把消息的尺寸與消息一塊發送
3.使用特殊的標識符來區分消息的間隔,注意這里這個間隔符不能出現在要發送的數據中.

HTTP協議詳解

HTTP協議詳解

問題1? HTTP和HTTPS的區別?

首先要回答這個問題,就必須知道有HTTP協議為什么還需要HTTPS協議?
超文本傳輸協議HTTP協議是用于web瀏覽器和服務器之間傳遞信息的,但是它在信息的傳遞
的過程中是明文的,不提供任何形式的數據加密.如果攻擊者攔截到了Web瀏覽器和服務器之間的報文,就可以直接讀取其中的內容.因此,HTTP協議不適合傳輸一些敏感的信息.例如銀行卡卡號,賬號密碼等支付信息.

so,為了解決HTTP明文傳送不安全的弊端,就推出了HTTPS這個協議.具體來說這個協議就是在HTTP協議的基礎上添加了SSL協議,這個協議可以對瀏覽器和服務器之間傳輸的報文進行加密,以及通過證書對服務器進行驗證.

HTTPS: 其實就是以安全為目標的HTTP通道,簡單的說就是HTTP的安全版.它使用安全套接字層(SSL secure sockets layer)進行信息交換,簡單的說它是HTTP的安全版.

總結 HTTP和HTTPS的區別?

  1. HTTP是明文傳輸文本的協議,而HTTPS是通過SSL安全套接字層進行加密之后的協議.
    2.HTTPS協議需要加入ca申請證書,一般免費證書很少,需要交費.
    3.HTTPS比HTTP多了兩個東西,一個是SSL加密,保證數據傳輸的安全性.另一個就是信任證書,確定服務器的來源是安全的.
    4.HTTPS和HTTP連接的時候使用的端口號是不一樣的,HTTPS默認是80端口,而后者是443.

問題2?簡述HTTP的一次全過程

HTTP請求的整個流程
上個圖先


1. 第一步DNS域名解析

通過域名解析,獲取到要連接的服務器的網路地址.

2. 建立TCP連接

三次握手,建立HTTP協議需要的支撐協議的TCP連接的三次握手.

3. 發起HTTP請求
瀏覽器發送報文,包括請求行,請求頭,請求體以空行結束,向服務器發送報文.

4. 服務器收到報文,并根據請求的內容作出響應.

5. 瀏覽器收到報文,根據報文的文件類型,進行相應,解析和顯示

注意HTTP1.0版本模式是短連接的,而HTTP1.1版本加入了長連接.如果瀏覽器或者服務器在其頭部加入了這行代碼:Connection:keep-alive

問題3?HTTP的長連接和短連接

什么是長連接和短連接?

短連接:

瀏覽器和服務器每進行一次HTTP操作(請求和響應),就建立一次連接,任務結束就中斷連接.舉個例子,比如瀏覽器訪問一個HTML頁面,包含有其他的web資源,例如js文件,圖片,css文件等,每遇到一個web資源,就會建立一個HTTP連接.在HTTP1.0中,采用的都是短連接

長連接:

從HTTP1.1中,默認采用的是長連接,通過在報文的頭部添加Connection:keep-alive來實現.當使用長連接的時候,客戶端和服務器之間建立的TCP的連接通道不會關閉,如果瀏覽器再請求這個服務器上的資源,可以使用這個連接.長連接也不是無限期的連接,它有一個保持時間,可以在服務器軟件中設定這個時間.

注意: HTTP的長連接和短連接,實際上是TCP的長短連接,并且必須瀏覽器和服務器同時都支持才可以

長連接和短連接的優缺點

  1. 長連接可以減少頻繁的創建和關閉連接,一定程度上節約了時間,減少浪費.對于請求和響應比較頻繁的操作來說,使用長連接比較合適.但是長連接存在一個問題,因為一直維持著連接,如果服務器上連接的瀏覽器用戶較多的時候,對服務器的負載來說是各考驗.這個時候服務器就要采取一些策略,比如關閉一些長時間沒有進行操作的連接.

2.短連接對于服務器來說管理較為簡單,存在的連接都是有用的連接,不需要額外的控制手段.但是如果客戶端請求比較頻繁,將會在TCP建立連接和關閉連接上浪費時間和寬帶.

什么時候使用長連接和短連接
長連接多用于操作頻繁,點對點的通信,而且連接數不能太多的情況.
而短連接適用于那些連接不是很頻繁,但是連接人數比較多的情況.

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,797評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,179評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,628評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,642評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,444評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,948評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,040評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,185評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,717評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,602評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,794評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,316評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,045評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,418評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,671評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,414評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,750評論 2 370

推薦閱讀更多精彩內容