網(wǎng)絡(luò)基礎(chǔ)知識

OSI網(wǎng)絡(luò)七層協(xié)議

  1. 物理層：
    負責(zé)將機器語言的0.1轉(zhuǎn)化為電壓高低，脈沖光的閃滅輸出給物理的傳輸介質(zhì)（光纖）缝裤。
  2. 數(shù)據(jù)鏈路層：
    負責(zé)物理層上的通信傳輸，把0.1序列化為有意義的數(shù)據(jù)幀傳給對端杨赤。通過Mac地址雹顺，目的是識別鏈接到同一傳輸介質(zhì)上的設(shè)備。因此厕鹃，這一把分層中mac地址信息的首部附加到網(wǎng)絡(luò)層轉(zhuǎn)發(fā)過來的數(shù)據(jù)上兢仰，發(fā)送到網(wǎng)絡(luò)。
  3. 網(wǎng)絡(luò)層：
    將數(shù)據(jù)傳輸?shù)侥繕说刂芳敛辏繕说刂房梢允怯啥鄠€網(wǎng)路或路由連接而成的某個地址把将，因此改層主要是尋找地址和路由的選擇。
  4. 傳輸層：
    主要是用戶負責(zé)建立兩端節(jié)點的通信關(guān)系忆矛，保證數(shù)據(jù)傳輸安全察蹲，傳輸是直接連接雙方節(jié)點的ip地址，不經(jīng)過路由處理催训。如果A發(fā)送給B消息洽议，傳輸過程中出現(xiàn)數(shù)據(jù)丟失或者網(wǎng)絡(luò)出現(xiàn)異常只發(fā)送了部分信息到達B端，B端會反饋消息漫拭，告訴A绞铃，只收到了部分消息，A會將未發(fā)送的消息重新發(fā)送到B嫂侍，比如迅雷下載資源的時候儿捧，可以暫停荚坞，下次繼續(xù)按照上一次的進度下載
  5. 會話層：負責(zé)網(wǎng)絡(luò)通信的建立和斷開，選擇網(wǎng)絡(luò)通信的連接方式菲盾，是GET,POST,長連接颓影，短連接。當(dāng)負責(zé)傳輸數(shù)據(jù)發(fā)送請求時懒鉴，把表示層的數(shù)據(jù)按照一定規(guī)律和標準拆分成數(shù)據(jù)塊（每個數(shù)據(jù)庫都有一個單獨的附加首部信息诡挂，標記接收端和發(fā)送端ip）。當(dāng)負責(zé)接收數(shù)據(jù)響應(yīng)請求時：負責(zé)把比特流數(shù)據(jù)根據(jù)數(shù)據(jù)的每個節(jié)點拼接成完整的數(shù)據(jù)临谱，會話層會在接收到接收到的數(shù)據(jù)前端附加首部信息璃俗，記錄數(shù)據(jù)的傳輸順序信息。
  6. 表示層： 數(shù)據(jù)的轉(zhuǎn)化層悉默。當(dāng)負責(zé)傳送數(shù)據(jù)發(fā)送請求時: 會將應(yīng)用層封裝的數(shù)據(jù)轉(zhuǎn)化成網(wǎng)絡(luò)通用的標準數(shù)據(jù)格式進行傳遞城豁，當(dāng)負責(zé)接收數(shù)據(jù)響應(yīng)請求時: 會將會話層傳入的網(wǎng)絡(luò)通用標準格式數(shù)據(jù)轉(zhuǎn)換為對應(yīng)設(shè)備的數(shù)據(jù)。不同設(shè)備對同一比特流數(shù)據(jù)的解析可能會有不同的結(jié)果抄课，表示層與表層之間為了識別編碼格式唱星，也會附加首部信息。
  7. 應(yīng)用層：
    當(dāng)負責(zé)傳送數(shù)據(jù)發(fā)送請求時: 把需要發(fā)送的數(shù)據(jù)跟磨，按照應(yīng)用的格式標準協(xié)議等封裝成對應(yīng)數(shù)據(jù)间聊。當(dāng)負責(zé)接收數(shù)據(jù)響應(yīng)請求時:把數(shù)據(jù)按照應(yīng)用的標準格式進行解析。例如在HTTP協(xié)議中抵拘，發(fā)送請求前要封裝請求頭哎榴，這些解析過程方式是根據(jù)應(yīng)用層的協(xié)議而定的，每個協(xié)議格式不一樣僵蛛。如果不同應(yīng)用標準格式不一樣尚蝌，會解析失敗，無法正確顯示數(shù)據(jù)內(nèi)容墩瞳，
    例如: A電腦是Mac電腦用的pages軟件寫一個文本驼壶，然后傳給Bwindows電腦氏豌，B電腦接收到的是A電腦的數(shù)據(jù)喉酌，數(shù)據(jù)格式完全跟A電腦一樣，但是B電腦上沒有能解析A電腦pages軟件數(shù)據(jù)的工具泵喘。所以B電腦用戶無法讀取該文件泪电，文件之所以無法解析不是因為電腦端不一樣，而是因為沒有乳尖解析對象數(shù)據(jù)格式的應(yīng)用纪铺，實際上數(shù)據(jù)格式的基本封裝是應(yīng)用層自身完成的相速，還沒有到應(yīng)用層這一步。拿HTTP說鲜锚，當(dāng)應(yīng)用封裝好需要傳輸?shù)臄?shù)據(jù)進行傳輸時（例如我們平時應(yīng)用中把數(shù)據(jù)封裝在字典里然后轉(zhuǎn)成json字符串突诬，這一步驟就是應(yīng)用本身的封裝）苫拍，應(yīng)用層會根據(jù)HTTP協(xié)議對數(shù)據(jù)進行處理（封裝成HTTP的請求頭），該協(xié)議會在傳輸?shù)臄?shù)據(jù)前端附加一個首部標簽旺隙，該首部標簽表明了發(fā)送數(shù)據(jù)內(nèi)容和發(fā)送的地址
    image.png

    iOS中把上三層應(yīng)用層
    image.png

    對于我們而言理解上也就主要是4個層绒极，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層蔬捷，傳輸層垄提，應(yīng)用層
    TCP/UDP協(xié)議
    TCP協(xié)議是面向連接、保證高可靠性(數(shù)據(jù)無丟失周拐、數(shù)據(jù)無失序铡俐、數(shù)據(jù)無錯誤、數(shù)據(jù)無重復(fù)到達)傳輸層協(xié)議妥粟。
    三次握手
  • 首先客戶端向服務(wù)器發(fā)起一個建立連接的同步請求(SYN)請求
  • 服務(wù)器在收到這個請求后向客戶端回復(fù)一個同步/確認（SYN/ACK）的應(yīng)答

  • 客戶端在收到應(yīng)答回應(yīng)之后再向服務(wù)端發(fā)送一個確認(ACK),此時TCP連接成功


    image.png

四次揮手

四次揮手.png

  • 首先客戶端發(fā)送一個FIN消息給服務(wù)端审丘，客戶端進入FIN_WAIT_1狀態(tài)

  • 接著服務(wù)器收到FIN后，發(fā)送一個ACK給客戶端罕容，確認序號為收到序號+1（與SYN相同备恤，一個FIN占一個序號）, 服務(wù)端進入CLOSE_WAIT狀態(tài)。

  • 服務(wù)端在回復(fù)完客戶端的TCP斷開請求后锦秒，不會馬上進行TCP斷開露泊，服務(wù)器會先確保斷開前，所有的傳輸?shù)臄?shù)據(jù)是否已經(jīng)傳輸完畢旅择，一旦確認數(shù)據(jù)傳輸完成惭笑，服務(wù)端發(fā)送一個FIN消息給客戶端，服務(wù)端進入LAST_ACK狀態(tài)生真。

  • 最后客戶端收到FIN消息后沉噩，進入TIME_WAIT狀態(tài)，接著發(fā)送一個ACK給Server柱蟀，確認序號為收到序號+1川蒙，
    服務(wù)端進入CLOSE轉(zhuǎn)臺，完成四次揮手长已。
    UDP協(xié)議
    UDP被稱之為用戶數(shù)據(jù)報協(xié)議位于傳輸層畜眨。提供非面向連接的網(wǎng)絡(luò)服務(wù)，傳送數(shù)據(jù)不需要和服務(wù)端建立連接术瓮，只需要知道數(shù)據(jù)需要發(fā)送到哪一個IP地址和監(jiān)聽端口即可康聂，該服務(wù)傳輸?shù)臄?shù)據(jù)是不可靠的、可以由一點發(fā)送到到多點胞四。這意味著它不保證數(shù)據(jù)報的到達只負責(zé)發(fā)送恬汁，也不保證所傳送數(shù)據(jù)包的順序是否正確。
    HTTP協(xié)議
    基本概念

  • 客戶端（Client）：移動應(yīng)用（iOS辜伟、android等應(yīng)用）

  • 服務(wù)器（Server）：為客戶端提供服務(wù)氓侧、提供數(shù)據(jù)脊另、提供資源的機器

  • 請求（Request）：客戶端向服務(wù)器索取數(shù)據(jù)的一種行為

  • 響應(yīng)（Response）：服務(wù)器對客戶端的請求做出的反應(yīng)，一般指返回數(shù)據(jù)給客戶端

HTTP協(xié)議的特點
HTTP協(xié)議永遠都是客戶端發(fā)起請求约巷，服務(wù)器回送響應(yīng)尝蠕。這樣就限制了使用HTTP協(xié)議，無法實現(xiàn)在客戶端沒有發(fā)起請求的時候载庭，服務(wù)器將消息推送給客戶端看彼。
GET和POST對比和區(qū)別
GET和POST的主要區(qū)別表現(xiàn)在數(shù)據(jù)傳遞上

GET：在請求URL后面以?的形式拼接發(fā)給服務(wù)器的參數(shù)，多個參數(shù)之間用&隔開囚聚。
比如http://www.test.com/login?username=123&pwd=234&type=JSON由于瀏覽器和服務(wù)器對URL長度有限制靖榕，因此在URL后面附帶的參數(shù)是有限制的，通常不能超過1KB
POST：發(fā)給服務(wù)器的參數(shù)全部放在請求體中顽铸，理論上茁计，POST傳遞的數(shù)據(jù)量沒有限制（具體還得看服務(wù)器的處理能力）
HTTPS
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer）：是以安全為目標的HTTP通道，簡單講是HTTP的安全版谓松。即HTTP下加入SSL層星压，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細內(nèi)容就需要SSL

image.png

HTTPS和HTTP的區(qū)別主要為以下四點：
https協(xié)議需要到ca申請證書鬼譬，一般免費證書很少娜膘，需要交費。
http是超文本傳輸協(xié)議优质，信息是明文傳輸竣贪，https 則是具有安全性的ssl加密傳輸協(xié)議。
http和https使用的是完全不同的連接方式巩螃，用的端口也不一樣演怎，前者是80，后者是443避乏。
http的連接很簡單爷耀，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸拍皮、身份認證的網(wǎng)絡(luò)協(xié)議歹叮，比http協(xié)議安全。
參考鏈接

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末春缕，一起剝皮案震驚了整個濱河市盗胀，隨后出現(xiàn)的幾起案子艘蹋，更是在濱河造成了極大的恐慌锄贼，老刑警劉巖，帶你破解...
    沈念sama閱讀 206,311評論 6贊 481
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件女阀，死亡現(xiàn)場離奇詭異宅荤，居然都是意外死亡屑迂，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,339評論 2贊 382
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門冯键，熙熙樓的掌柜王于貴愁眉苦臉地迎上來惹盼，“玉大人，你說我怎么就攤上這事惫确∈直ǎ” “怎么了？”我有些...
    開封第一講書人閱讀 152,671評論 0贊 342
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵改化，是天一觀的道長掩蛤。 經(jīng)常有香客問我，道長陈肛，這世上最難降的妖魔是什么揍鸟？ 我笑而不...
    開封第一講書人閱讀 55,252評論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮句旱，結(jié)果婚禮上阳藻，老公的妹妹穿的比我還像新娘。我一直安慰自己谈撒，他們只是感情好腥泥，可當(dāng)我...
    茶點故事閱讀 64,253評論 5贊 371
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著啃匿，像睡著了一般道川。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上立宜，一...
    開封第一講書人閱讀 49,031評論 1贊 285
  • 城市分裂傳說
    那天冒萄，我揣著相機與錄音，去河邊找鬼橙数。 笑死尊流，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的灯帮。 我是一名探鬼主播崖技，決...
    沈念sama閱讀 38,340評論 3贊 399
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼钟哥！你這毒婦竟也來了迎献？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 36,973評論 0贊 259
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤腻贰，失蹤者是張志新（化名）和其女友劉穎吁恍，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 43,466評論 1贊 300
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡冀瓦，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 35,937評論 2贊 323
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年伴奥，在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片翼闽。...
    茶點故事閱讀 38,039評論 1贊 333
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡拾徙，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出感局，到底是詐尸還是另有隱情尼啡，我是刑警寧澤，帶...
    沈念sama閱讀 33,701評論 4贊 323
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布询微，位于F島的核電站玄叠，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏拓提。R本人自食惡果不足惜读恃，卻給世界環(huán)境...
    茶點故事閱讀 39,254評論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望代态。 院中可真熱鬧寺惫，春花似錦、人聲如沸蹦疑。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,259評論 0贊 19
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽歉摧。三九已至艇肴，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間叁温，已是汗流浹背再悼。 一陣腳步聲響...
    開封第一講書人閱讀 31,485評論 1贊 262
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留膝但，地道東北人冲九。 一個月前我還...
    沈念sama閱讀 45,497評論 2贊 354
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像跟束，于是被迫代替她去往敵國和親莺奸。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 42,786評論 2贊 345