通訊協議是什麼?(ftp、
http、
https、
file...)
交流的規則
舉例:
漢語、英語、法語、德語
(百度百科:通訊協議) 通訊協議是指雙方實體完成通訊或服務所必須遵循的規則和約定。經過通訊信道和設備互連起來的多個不一樣地理位置的數據通訊系統,要使其能協同工做實現信息交換和資源共享,它們之間必須具備共同的語言。交流什麼、怎樣交流及什麼時候交流,都必須遵循某種互相都能接受的規則。這個規則就是通訊協議。
IP協議 Internet Protocol
(百度百科:IP協議)IP協議是用於將多個包交換網絡鏈接起來的,它在源地址和目的地址之間傳送一種稱之爲數據包的東西,它還提供對數據大小的從新組裝功能,以適應不一樣網絡對包大小的要求。
4個字節, 一共32位
子網掩碼 的做用? 255.255.255.0
確認兩臺計算機是否處於同一網段
TCP、UDP的區別
若是TCP比做是打電話,那麼UDP就是在發短信
TCP(Transmission Control Protocol 傳輸控制協議)是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議
(通訊以前必須先創建鏈接)
因而,TCP相對可靠,它創建鏈接的過程稱爲3次握手
第一個特色:
三次握手,創建鏈接
第二個特色:
全部的消息,須要對方確認送達。
"土豆,土豆,我是茄子,收到請回答"
"茄子,茄子,我是土豆,收到消息"
當消息發送失敗,則對當前消息開始進行重複發送,直至收到迴應爲止。
"茄子,茄子,我是土豆,我被人油炸了,我更名叫薯片,收到請回答"
............
"茄子,茄子,我是土豆,我被人油炸了,我更名叫薯片,收到請回答,第2遍"
............
"茄子,茄子,我是土豆,我被人油炸了,我更名叫薯片,收到請回答,第3遍"
............
"薯片,薯片,我收到消息"
所以能夠確保數據的準確送達
舉例:
局域網遊戲,每每都有這樣的特色,當多人聯機對戰時,如有一我的掉線
其餘全部玩家進入讀秒狀態,那麼說明玩家和玩家之間採用了TCP協議。
由於對於遊戲來說,它不容許丟失任何數據,否則有可能出現兩邊不一致的狀況:
我這邊畫面一刀把你砍死了,你那邊畫面卻吃了個大血瓶抗住了。。。。。
UDP面向數據報的協議 (不可靠的協議)
(百度百科 UDP)UDP 是User Datagram Protocol的簡稱, 中文名是用戶數據報協議,是OSI(Open System Interconnection,開放式系統互聯) 參考模型中一種無鏈接的傳輸層協議,提供面向事務的簡單不可靠信息傳送服務,
無需創建鏈接
發送消息也無需對方確認
沒法保證數據的發送順序,以及準確率
數據的發送順序是 a.........b.........c...........d
因爲網路延遲的緣由,對方收到數據的順序有多是b...........d..........a
UDP一般用於視頻、語音等通訊(丟掉了一幀畫面是無所謂的)(局域網cs)
相對於TCP「效率」可能會更高
HTTP(無狀態的協議)
基於TCP協議的一種高級協議, 用於客戶端和服務器直接的通訊
超文本傳輸協議
(HTTP,HyperText Transfer Protocol)
Socket
(socket是一種網路通訊模型,由伯克利大學發明,因爲其優秀的設計後被各大編程語言所採用)
//如下是JAVA使用socket連接百度服務器,請求首頁的代碼
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.Socket;
public class ClientSocket {
public static void main(String[] args) throws Exception {
Socket skt = new Socket("61.135.169.125",80);
BufferedWriter bw = new BufferedWriter( new OutputStreamWriter( skt.getOutputStream() ) );
bw.write("GET / HTTP/1.1");
bw.newLine();
bw.write("Host: www.baidu.com:80");
bw.newLine();
bw.write("Content-Type: text/html");
bw.newLine();
bw.newLine();
bw.flush();
//GET / HTTP/1.1
//Host: localhost:8080
//Content-Type: text/html
BufferedReader br = new BufferedReader(new InputStreamReader(skt.getInputStream()));
String str = null;
while( (str = br.readLine()) != null) {
System.out.println(str);
}
}
}
反覆觀察上面這個SOCKET程序的運行結果,你能看的出來麼?這種通訊最大的問題在哪?
問題就在於每次收到返回的頁面,鏈接都斷開了。
所以HTTP這種無狀態的協議,最大的特色就是,你掛斷了電話老子還怎麼通信?!
剛剛提交過的用戶名密碼(登陸動做),
下次請求服務器(例如查詢帳戶餘額),難道還要從新驗證身份?
因而cookie就出現了
COOKIE的誕生,爲何叫會話跟蹤技術?
在一次會話從開始到結束的整個過程,全程跟蹤記錄客戶端的狀態(例如:是否登陸、購物車信息、是否已下載、是否已點贊、視頻播放進度等等)
你把COOKIE就當成是第一次跟服務器鏈接後,服務器發給你的身份牌,上面就記錄跟你有關的信息
之後只要再跟服務器通訊,必須帶着這個身份牌
這樣一來,關於你是誰? 有沒有登錄過? 購物車裏有什麼信息? 服務器固然就很容易知道了。
這裏面固然還有不少的安全隱患,也有相應的解決辦法,這個不在咱們今天的討論範圍。
cookie的核心應用(本意)就是驗證身份,順帶存取一些體積小的數據,其主要目的是用於身份的驗證
這也是後來H5出現LocalStorage,sessionStorage 的緣由
cookie有哪些特色?(基本都是從安全考慮)
1 只能使用文本文件(防止寫入病毒)
(若是瀏覽器能夠隨意在客戶端機器上生成文件,好比身份牌是個定時炸彈,安全問題將會變得很是嚴重)
2 文件有大小限制 4KB (通常狀況下,同一域名下爲4KB,防止佔用空間過大)
(文件若沒有大小限制,好比身份牌的重量是140斤,掛脖子能不能累死?)
3 數量限制 (個別瀏覽器)
(通常瀏覽器,限制大概在50條左右,你家的門禁卡里能存的下一部藍光高清麼?
)
4 讀取有域名限制 (同源策略,必須是同一個來源才能獲取,保證數據安全)
不可跨域讀取,只能由來自 寫入cookie的 同一域名 的網頁可進行讀取。
簡單的講就是,誰寫的cookie,誰纔有權利讀取
(身份牌是我發你的,固然只有我能讀取,你媳婦兒的手機自動鏈接了鄰居老王家的wifi,你知道這意味着什麼嗎?)
5 時效限制
每一個cookie都有時效,最短的有效期是,會話級別:
就是當瀏覽器關閉,那麼cookie當即銷燬
(安全學基本理論:密碼鎖每次打開都須要從新輸入密碼,輸入一次密碼,之後就再也不驗證,就沒有安全可言
問: 信用卡爲何會有過時時間?
)
Cookie的流程圖
若是有時候,咱們須要這個網頁長時間跟服務器保持鏈接,好比說即時通信、語音、視頻等等
HTML5的websocket,試圖解決這個問題
在websocket沒有誕生以來,解決這個問題是極爲困難的。
一般有兩種作法:ajax輪詢和 comet技術
第一種:ajax輪詢
var getting = {
url:'server.php',
dataType:'json',
success:function(res) {
console.log(res);
}
};
//關鍵在這裏,Ajax定時訪問服務端,不斷獲取數據 ,這裏是1秒請求一次。
window.setInterval(function(){$.ajax(getting)},1000);
第二種 : comet技術
這個是利用了HTTP協議的1.1版本中新推出的長鏈接
咦?這名字聽上去好像不錯,若是鏈接能夠長時間保持不斷開,那問題不就解決了嗎?
其實長鏈接僅僅只是延長了鏈接時間,能夠在一次鏈接中出現不少個request和response
可是在即時通信這樣的功能裏面,因爲客戶端不知道消息什麼時候發過來?
咱們須要服務器主動的向客戶端推送消息。但長鏈接並不能作到這一點。
由於在HTPP協議的特色中,服務器的response必須是在收到了客戶的request後才能產生的
說白了,你請求一次,服務器返回一次,你不請求,服務器不能主動返回
因而,高手們想到了這樣一個辦法
"有新消息嗎? 不!我不聽!不要告訴我沒有!等有新消息了你再回答我!" //第一次requrest,長鏈接已經開始
............過了一會
"有新消息了" //服務器返回,第一次response
"哈哈哈,好興奮"//客戶端接收結果並處理,此時鏈接沒有斷開
"還有新消息嗎?等有新消息了再回答我吧!" //第二次requrest
............過了一會
"有新消息了" //服務器再次返回,第二次response
這樣作看起來,好像是服務器主動發送了消息,其實每次咱們都要先發請求,只不過沒有消息的時候這個請求被阻塞了而已
很差的地方在於,它消耗了大量程序資源,程序除了處理業務邏輯,還要負責管理這個請求
WebSokcet是一種HTTP1.1協議的加強版,就像socket程序同樣,消息能夠隨時發送,隨時接受
咱們的服務器從被動的返回,變成了主動的發送
"有新消息嗎?有了通知我"
//第1次requrest,鏈接上了
............過了一會
"有新消息了"
//
第1次response,鏈接保持中...
............過了一會
"又有新消息了"
//
第2次response,
鏈接保持中...
............又過了一會
"又有新消息了"
//
第3次response,
鏈接保持中...
它還有一個巨大的好處就是,
這個鏈接的保持能夠再也不由程序處理
想象這樣一個場景:
Twitter上有成千上萬的用戶,每秒鐘有幾十萬人同時跟服務器作鏈接,作信息交換。程序能處理的了這麼多的鏈接麼?
因而咱們考慮這樣一種模型:
google瀏覽器對cookie要求比較嚴格,file協議下(無域名)的cookie操做是不被容許的
手動更改電腦時間,當cookie到期後不會消失,只是取不出來,由於cookie過時時間實際上是一個倒計時的定時器
清空cookie,一、覆蓋(同一路徑下) 二、到期時間設置爲當前session
document.cookie ="";(會自動轉爲字符串)
cookie 中的 path 做用域同 全局變量與局部變量的做用域關係相似
var Cookie = {
get: function(key){
var cookiestr = document.cookie;
var list = cookiestr.split("; ");
for(var i=0; i<list.length; i++){
var kvs = list[i].split("=");
if(kvs[0]==key) {
return kvs[1];
}
}
return null;
},
set: function(key,value,expires,path){//鍵、值、存在時間(數字、字母、日期)、路徑
if( (typeof expires == "number") || (typeof expires == "string")) {
expires = Number(expires);
if(isNaN(expires)) {
expires = undefined;
} else {
var d = new Date();
d.setDate(d.getDate()+expires);
expires = d;
}
}
if( !(expires instanceof Date) && typeof expires == "object") {
expires = undefined;
}
document.cookie = key+"="+value+";" + (expires?"expires="+expires+";":"") + (path?"path="+path+";":"");
}
}
注:cookie中只能存文本,所以不能存取對象,可用JSON.stringify() 和JSON.parse() 轉換後存取
jquery.cookie.js 使用:
//Query操做cookie的插件,大概的使用方法以下
$.cookie('the_cookie'); //讀取Cookie值
$.cookie(’the_cookie’, ‘the_value’); //設置cookie的值
$.cookie(’the_cookie’, ‘the_value’, {expires: 7, path: ‘/’, domain: ‘jquery.com’, secure: true});//新建一個cookie 包括有效期 路徑 域名等
$.cookie(’the_cookie’, ‘the_value’); //新建cookie
$.cookie(’the_cookie’, null); //刪除一個cookie