1.計算機網絡
1. OSI 開放式系統互聯通信參考模型（英語：Open System Interconnection Reference Model，縮寫爲 OSI），簡稱爲OSI模型（OSI model），一種概念模型，由國際標準化組織提出，一個試圖使各種計算機在世界範圍內互連爲網絡的標準框架。
層 作用 數據單位 協議
物理層 通過媒介傳輸比特,確定機械及電氣規範 比特Bit RJ45、CLOCK、IEEE802.3 （中繼器，集線器）
數據鏈路層 將比特組裝成幀和點到點的傳遞 幀Frame PPP、FR、HDLC、VLAN、MAC （網橋，交換機）
網絡層 負責數據包從源到宿的傳遞和網際互連 包PackeT IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP（路由器）
傳輸層 提供端到端的可靠報文傳遞和錯誤恢復 段Segment TCP、UDP、SPX
會話層 建立、管理和終止會話 會話協議數據單元 NFS、SQL、NETBIOS、RPC
表示層 對數據進行翻譯、加密和壓縮 表示協議數據單元 JPEG、MPEG、ASII
應用層 允許訪問OSI環境的手段 應用協議數據單元 FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS
交換機與路由器有什麼區別？
①工作所處的OSI層次不一樣，交換機工作在OSI第二層數據鏈路層，路由器工作在OSI第三層網絡層
②尋址方式不同：交換機根據MAC地址尋址，路由器根據IP地址尋址
③轉發速不同：交換機的轉發速度快，路由器轉發速度相對較慢。
TCP/IP協議族：分層（4層）：網絡接口層、 網際層、運輸層、 應用層。
五層協議 （5層）：物理層、數據鏈路層、網絡層、運輸層、 應用層。
數據傳輸的基本單位：傳輸層（TCP（報文段）UDP（用戶數據包））、網絡層（IP數據報或分組）、數據鏈路層（幀）、物理層（比特）
2.TCP和UDP的區別
TCP是傳輸控制協議，提供的是面向連接、可靠的字節流服務。通信雙方彼此交換數據前，必須先通過三次握手協議建立連接，之後才能傳輸數據。TCP提供超時重傳，丟棄重複數據，檢驗數據，流量控制等功能，保證數據能從一端傳到另一端。
UDP是用戶數據報協議，是一個簡單的面向無連接的協議。UDP不提供可靠的服務。在數據數據前不用建立連接故而傳輸速度很快。UDP主要用戶流媒體傳輸，IP電話等對數據可靠性要求不是很高的場合。
TCP是面向字節流的，UDP是面向報文的；
TCP ------------------------- UDP
連接方式 面向連接的、可靠的數據流傳輸 // 非面向連接的、不可靠的數據流傳輸
通信方式 一對一、點對點 // 一對一、一對多、多對一、多對多
傳輸單位 TCP報文段 // 用戶數據報
對系統資源要求 較多（TCP的20個字節信息包），負載高，採用虛電路 // 較少（UDP信息包的標題很短，只有8個字節）
安全性 可靠，安全 // 數據傳輸快，但是不可靠（盡最大努力交付）
對應協議 FTP、Telnet、SMTP、POP3、HTTP // DNS、SNMP、TFTP
TCP提供超時重發、丟棄重複數據、檢驗數據、窗口技術、流量控制等功能，保證數據能傳到另外一端。
UDP常用於QQ等即時通訊軟件（適合於實時通信，當網絡阻塞時，不影響發送端的發送效率。
UDP是一個無連結的數據報協議。它是一個“盡力傳遞”（best effort）或者說“不可靠”協議——不是因爲它特別不可靠，而是因爲它不檢查數據包是否已經到達目的地，並且不保證它們按順序到達。如果一個應用程序需要這些特性，那它必須自行檢測和判斷，或者使用TCP協議。 UDP的典型性應用是如流媒體（音頻和視頻等）這樣按時到達比可靠性更重要的應用，或者如DNS查找這樣的簡單查詢／響應應用，如果創建可靠的連結所作的額外工作將是不成比例地大。
TCP對應的協議
（1） FTP：定義了文件傳輸協議，使用21端口。
（2） Telnet：一種用於遠程登陸的端口，使用23端口，用戶可以以自己的身份遠程連接到計算機上，可提供基於DOS模式下的通信服務。
（3） SMTP：郵件傳送協議，用於發送郵件。服務器開放的是25號端口。
（4） POP3：它是和SMTP對應，POP3用於接收郵件。POP3協議所用的是110端口。
（5） HTTP：是從Web服務器傳輸超文本到本地瀏覽器的傳送協議。
UDP對應的協議
（1） DNS：用於域名解析服務，將域名地址轉換爲IP地址。DNS用的是53號端口。
（2） SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。由於網絡設備很多，無連接的服務就體現出其優勢。
（3） TFTP(Trival File Transfer Protocal)，簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務。
3.TCP三次握手和四次揮手的全過程
三次握手（我要和你建立鏈接；你真的要和我建立鏈接麼；我真的要和你建立鏈接=> 成功）
第一次握手：客戶端發送syn包(syn=x)到服務器，並進入SYN_SEND狀態，等待服務器確認；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=y+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包裏不包含數據，三次握手完畢後，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉連接之前，TCP 連接都將被一直保持下去。
爲什麼會採用三次握手，若採用二次握手可以嗎？- 不可以
“三次握手”的目的是“爲了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤”。 client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間纔到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認爲是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用“三次握手”，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以爲新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛纔那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。主要目的防止server端一直等待，浪費資源。
四次揮手（我要和你斷開鏈接；好的，斷吧；我也要和你斷開鏈接；好的，斷吧）
與建立連接的“三次握手”類似，斷開一個TCP連接則需要“四次握手”。
第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發數據了(當然，在fin包之前發送出去的數據，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些數據)，但是，此時主動關閉方還可以接受數據。
第二次揮手：被動關閉方收到FIN包後，發送一個ACK給對方，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號）。
第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，我的數據也發送完了，不會再給你發數據了。
第四次揮手：主動關閉方收到FIN後，發送一個ACK給被動關閉方，確認序號爲收到序號+1，然後進入等待 TIME_WAIT 狀態。被動方收到發起方的報文段以後關閉連接。發起方等待一定時間未收到回覆，則正常關閉。
TCP四次揮手 TIME_WAIT出現在哪， 爲什麼要有TIME_WAIT
爲什麼會採用四次揮手，若採用三次揮手可以嗎？
因爲TCP有個半關閉狀態，假設A.B要釋放連接，那麼A發送一個釋放連接報文給B，B收到後發送確認，這個時候A不發數據，但是B如果發數據A還是要接受，這叫半關閉。然後B還要發給A連接釋放報文，然後A發確認，所以是4次。
在tcp連接握手時爲何ACK是和SYN一起發送，這裏ACK卻沒有和FIN一起發送呢。原因是因爲tcp是全雙工模式，接收到FIN時意味將沒有數據再發來，但是還是可以繼續發送數據。
====================================
因爲關閉連接時，server端收到客戶端的FIN報文，並不會立即關閉socket，只能先回復一個ACK告訴client我已經收到你的關閉請求了，同時可能server還有數據沒傳輸完，只有等server端數據傳輸完成了 才能發送FIN報文，所以這個地方要分兩次發送，這樣就有了四次揮手。
-服務端的Time_Wait狀態再哪個階段出現？持續多久？爲什麼要設計這麼一個狀態？
timewait階段是最後階段發送確認收到server端的fin報文釋放連接請求後回覆給server端ack報文，之後client端就進入time_wait階段.
持續多久即是 問爲什麼不馬上關閉直接進入closed階段，主要是考慮到網絡的不可靠，假如client最後階段發送給server端的ack報文由於網絡原因丟失了server沒收到呢，server端會重新發送fin報文過來，這個時候client端就要等.
等多久？等一個計時器時間2MSL，如果該時間段內再次收到server的fin報文 那client就必須回覆. 如果沒有收到，client就認爲server端已經接收到了最後的ack報文.
HTTP：
URI和URL的區別：
URI是同一資源標誌符，可以唯一標識一個資源
URL是同一資源定位符，可以提供該資源的路徑，URL是URI的子集。
舉個例子：
身份證號就是URI，通過身份證號讓我們能且僅能確定一個人。
如果採用URL方式：動物住址協議://地球/中國/浙江省/杭州市/西湖區/某個大學/12宿舍樓/23號
HTTP和HTTPS的區別
Http協議運行在TCP之上，明文傳輸，客戶端和服務器都無法驗證對方身份。Https是身披SSL(Secure Socket Layer)外殼的Http，運行於SSL上，SSL運行與TCP上，是添加了加密和認證機制的HTTP。
二者之間存在如下不同：
端口不同：Http與Https使用了不同的連接方式，用的端口也不一樣，前者是80，後者是443；
資源消耗：和Http通信相比，Https通信由於加解密處理消耗更多的CPU和內存資源；
開銷：Https通信需要證書，而證書一般需要向認證機構購買；
共享密鑰加密：
加密和解密都使用同一密鑰的方式稱爲共享密鑰方式稱爲共享密鑰加密，也被稱爲對稱密鑰加密。
公開密鑰加密：
公開密鑰加密使用一對非對稱的密鑰，一把叫做私有密鑰，另一把叫做公開密鑰。發送密文的一方使用對方的公開密鑰進行加密處理，對方接收到被加密的信息後，在使用自己的私有密鑰進行解密。
HTTPS採用混合加密機制：HTTPS採用共享加密和公開加密兩者並用的混合加密機制。因爲公開密鑰加密和共享密鑰加密相比，處理速度慢，所以我們採用交換密鑰環節使用公開密鑰加密方式，之後的建立通信交換報文階段則採用共享密鑰加密方式
區別：
http是超文本傳輸協議，它時使用明文的方式發送我們的內容（沒有任何的加密），比如我們訪問了一個網址，我們需要在這個網址輸入密碼、登錄賬號之類的操作，我們的賬號和密碼就會發送到網址的服務器上面，但如果有人在中途截取了我們的信息，那麼我們的重要的信息就暴露了，爲了解決Http在傳輸中不加密的問題，之後就增加了一個SSL協議，這個協議提供網絡連接的加密，如果我們訪問一個https的網站，我們的電腦會先和服務器建立一個安全的連接通道，然後服務器會先發送一份網址的安全信息證書到我們的電腦，告訴我們的電腦，訪問的服務器沒有問題，確認了信息後，服務器就會生成一個加鎖的箱子，但是這把鎖有兩把不一樣的鑰匙，一把時給我們的電腦的，一把是給服務器自己，然後服務器會把沒有上鎖的箱子和鑰匙發給我們的電腦，我們把信息放在箱子裏面然後用鑰匙鎖上，然後發給服務器，服務器用自己的鑰匙打開箱子來保證信息的安全。
Http請求解析過程
瀏覽器輸入一個連接，到展示到頁面，經過了什麼
(1). 瀏覽器查詢 DNS，獲取域名對應的IP地址 :具體過程包括瀏覽器搜索自身的DNS緩存、搜索操作系統的DNS緩存、讀取本地的Host文件和向本地DNS服務器進行查詢等。對於向本地DNS服務器進行查詢，如果要查詢的域名包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析(此解析具有權威性)；如果要查詢的域名不由本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析（此解析不具有權威性）。如果本地域名服務器並未緩存該網址映射關係，那麼將根據其設置發起遞歸查詢或者迭代查詢；
(2). 瀏覽器獲得域名對應的IP地址以後，瀏覽器向服務器請求建立鏈接，發起三次握手；
(3). TCP/IP鏈接建立起來後，瀏覽器向服務器發送HTTP請求；
(4). 服務器接收到這個請求，並根據路徑參數映射到特定的請求處理器進行處理，並將處理結果返回給瀏覽器；
(5). 瀏覽器解析並渲染視圖，若遇到對js文件、css文件及圖片等靜態資源的引用，則重複上述步驟並向服務器請求這些資源；
(6). 瀏覽器根據其請求到的資源、數據渲染頁面，最終向用戶呈現一個完整的頁面。
Session、Cookie
Cookie和Session都是客戶端與服務器之間保持狀態的解決方案，具體來說，cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。
(1). Cookie
Cookie實際上是一小段的文本信息。
Cookie的工作原理：客戶端發送一個請求，服務器會爲張三產生一個唯一的識別碼，並以此作爲索引在服務器的後端數據庫生成一個項目，接着在給客戶端的HTTP響應報文中添加了叫做Set-Cookie的首部字段信息，客戶端會保存Cookie。當客戶端第二次往服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。服務器端發現客戶端發送過來的Cookie後，會檢查究竟是從哪個客戶端發送來的連接請求，然後對比服務器上的記錄，最後得到狀態信息。
====================================================
客戶端請求服務器，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie，而客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器，服務器檢查該Cookie，以此來辨認用戶狀態。服務器還可以根據需要修改Cookie的內容。
(2). Session
同樣地，會話狀態也可以保存在服務器端。客戶端請求服務器，如果服務器記錄該用戶狀態，就獲取Session來保存狀態，這時，如果服務器已經爲此客戶端創建過session，服務器就按照sessionid把這個session檢索出來使用；如果客戶端請求不包含sessionid，則爲此客戶端創建一個session並且生成一個與此session相關聯的sessionid，並將這個sessionid在本次響應中返回給客戶端保存。保存這個sessionid的方式可以採用 cookie機制 ，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發揮給服務器；若瀏覽器禁用Cookie的話，可以通過 URL重寫機制 將sessionid傳回服務器。
(3). Session 與 Cookie 的對比
-
實現機制：Session的實現常常依賴於Cookie機制，通過Cookie機制回傳SessionID；
-
大小限制：Cookie有大小限制並且瀏覽器對每個站點也有cookie的個數限制，Session沒有大小限制，理論上只與服務器的內存大小有關；
-
安全性：Cookie存在安全隱患，通過攔截或本地文件找得到cookie後可以進行攻擊，而Session由於保存在服務器端，相對更加安全；
-
服務器資源消耗：Session是保存在服務器端上會存在一段時間纔會消失，如果session過多會增加服務器的壓力。
4.IP地址
IP地址是指互聯網協議地址，是IP協議提供的一種統一的地址格式，它爲互聯網上的每一個網絡和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差異。IP地址編址方案將IP地址空間劃分爲A、B、C、D、E五類，其中A、B、C是基本類，D、E類作爲多播和保留使用，爲特殊地址。
每個IP地址包括兩個標識碼（ID），即網絡ID和主機ID。同一個物理網絡上的所有主機都使用同一個網絡ID，網絡上的一個主機（包括網絡上工作站，服務器和路由器等）有一個主機ID與其對應。
-
IP地址分爲兩個部分，網絡號和主機號。
A類地址：以0開頭， 第一個字節範圍：1~126（1.0.0.0 - 126.255.255.255）；
B類地址：以10開頭， 第一個字節範圍：128~191（128.0.0.0 - 191.255.255.255）；
C類地址：以110開頭， 第一個字節範圍：192~223（192.0.0.0 - 223.255.255.255）；
D類地址：以1110開頭，第一個字節範圍：224~239（224.0.0.0 - 239.255.255.255）；（作爲多播使用）
E類地址：以1111開頭，保留
其中A、B、C是基本類，D、E類作爲多播和保留使用。以下是留用的內部私有地址：
A類 10.0.0.0–10.255.255.255
B類 172.16.0.0–172.31.255.255
C類 192.168.0.0–192.168.255.255IP地址與子網掩碼相與得到網絡號：
ip : 192.168.2.110
&Submask : 255.255.255.0
網絡號 ：192.168.2 .0
注: 主機號，全爲0的是網絡號（例如：192.168.2.0），主機號全爲1的爲廣播地址（192.168.2.255）
1). A類地址：1字節的
網絡地址 + 3字節主機地址，網絡地址的最高位必須是“0”
一個A類IP地址是指， 在IP地址的四段號碼中，第一段號碼爲網絡號碼，剩下的三段號碼爲本地計算機的號碼。如果用二進制表示IP地址的話，A類IP地址就由1字節的網絡地址和3字節主機地址組成，網絡地址的最高位必須是“0”。A類IP地址中網絡的標識長度爲8位，主機標識的長度爲24位，A類網絡地址數量較少，有126個網絡，每個網絡可以容納主機數達1600多萬臺。
A類IP地址的地址範圍1.0.0.0到127.255.255.255（二進制表示爲：00000001 00000000 00000000 00000000 - 01111110 11111111 11111111 11111111），最後一個是廣播地址。A類IP地址的子網掩碼爲255.0.0.0，每個網絡支持的最大主機數爲256的3次方-2=16777214臺。
2). B類地址: 2字節的網絡地址 + 2字節主機地址，網絡地址的最高位必須是“10”
一個B類IP地址是指，在IP地址的四段號碼中，前兩段號碼爲網絡號碼。如果用二進制表示IP地址的話，B類IP地址就由2字節的網絡地址和2字節主機地址組成，網絡地址的最高位必須是“10”。B類IP地址中網絡的標識長度爲16位，主機標識的長度爲16位，B類網絡地址適用於中等規模的網絡，有16384個網絡，每個網絡所能容納的計算機數爲6萬多臺。
B類IP地址地址範圍128.0.0.0-191.255.255.255（二進制表示爲：10000000 00000000 00000000 00000000—-10111111 11111111 11111111 11111111），最後一個是廣播地址。B類IP地址的子網掩碼爲255.255.0.0，每個網絡支持的最大主機數爲256的2次方-2=65534臺。
3). C類地址: 3字節的網絡地址 + 1字節主機地址，網絡地址的最高位必須是“110”
一個C類IP地址是指，在IP地址的四段號碼中，前三段號碼爲網絡號碼，剩下的一段號碼爲本地計算機的號碼。如果用二進制表示IP地址的話，C類IP地址就由3字節的網絡地址和1字節主機地址組成，網絡地址的最高位必須是“110”。C類IP地址中網絡的標識長度爲24位，主機標識的長度爲8位，C類網絡地址數量較多，有209萬餘個網絡。適用於小規模的局域網絡，每個網絡最多隻能包含254臺計算機。
C類IP地址範圍192.0.0.0-223.255.255.255（二進制表示爲: 11000000 00000000 00000000 00000000 - 11011111 11111111 11111111 11111111）。C類IP地址的子網掩碼爲255.255.255.0，每個網絡支持的最大主機數爲256-2=254臺。
4). D類地址:多播地址，用於1對多通信，最高位必須是“1110”
D類IP地址在歷史上被叫做多播地址(multicast address)，即組播地址。在以太網中，多播地址命名了一組應該在這個網絡中應用接收到一個分組的站點。多播地址的最高位必須是“1110”，範圍從224.0.0.0到239.255.255.255。
5). E類地址:爲保留地址，最高位必須是“1111”
5.ARP和RARP
ARP地址解析協議
ARP是地址解析協議，作用是完成IP地址到硬件MAC地址的映射。
工作流程：
(1)首先，每個主機都會在自己的ARP緩衝區中建立一個ARP列表，以表示IP地址和MAC地址之間的對應關係。
（2）當源主機要發送數據時，首先檢查ARP列表中是否有對應IP地址的目的主機的MAC地址，如果有，則直接發送數據，如果沒有，就向本網段的所有主機發送ARP數據包，該數據包包括的內容有：源主機IP地址，源主機MAC地址，目的主機的IP地址。
（3）當本網絡的所有主機收到該ARP數據包時，首先檢查數據包中的IP地址是否是自己的IP地址，如果不是，則忽略該數據包，如果是，則首先從數據包中取出源主機的IP和MAC地址寫入到ARP列表中，如果已經存在，則覆蓋，然後將自己的MAC地址寫入ARP響應包中，告訴源主機自己是它想要找的MAC地址。
（4）源主機收到ARP響應包後。將目的主機的IP和MAC地址寫入ARP列表，並利用此信息發送數據。如果源主機一直沒有收到ARP響應數據包，表示ARP查詢失敗。
廣播發送ARP請求，單播發送ARP響應。
RARP逆地址解析協議
RARP是逆地址解析協議，作用是完成硬件地址到IP地址的映射，主要用於無盤工作站，因爲給無盤工作站配置的IP地址不能保存。
工作流程：在網絡中配置一臺RARP服務器，裏面保存着IP地址和MAC地址的映射關係，當無盤工作站啓動後，就封裝一個RARP數據包，裏面有其MAC地址，然後廣播到網絡上去，當服務器收到請求包後，就查找對應的MAC地址的IP地址裝入響應報文中發回給請求者。因爲需要廣播請求報文，因此RARP只能用於具有廣播能力的網絡。
6.HTTP和HTTPS
HTTP協議：超文本傳輸協議，是一個屬於應用層的面向對象的協議，由於其簡捷、快速的方式，適用於分佈式超媒體信息系統。
7.瀏覽器請求
【在瀏覽器中輸入www.baidu.com後執行的全部過程】
客戶端瀏覽器通過DNS解析到www.baidu.com 的IP地址220.181.27.48，通過這個IP地址找到客戶端到服務器的路徑。客戶端瀏覽器發起一個HTTP會話到220.181.27.48，然後通過TCP進行封裝數據包，輸入到網絡層。
在客戶端的傳輸層，把HTTP會話請求分成報文段，添加源和目的端口，如服務器使用80端口監聽客戶端的請求，客戶端由系統隨機選擇一個端口如5000，與服務器進行交換，服務器把相應的請求返回給客戶端的5000端口。然後使用IP層的IP地址查找目的端。
客戶端的網絡層不用關心應用層或者傳輸層的東西，主要做的是通過查找路由表確定如何到達服務器，期間可能經過多個路由器，這些都是由路由器來完成的工作，我不作過多的描述，無非就是通過查找路由表決定通過那個路徑到達服務器。
客戶端的鏈路層，包通過鏈路層發送到路由器，通過鄰居協議查找給定IP地址的MAC地址，然後發送ARP請求查找目的地址，如果得到迴應後就可以使用ARP的請求應答交換的IP數據包現在就可以傳輸了，然後發送IP數據包到達服務器的地址。
8.cookie，session區別，應用場景
保存登錄狀態用什麼？Cookie ,Session
Cookie 是在HTTP協議下，服務器或腳本可以維護客戶工作站上信息的一種方式。Cookie信息,可以看作是瀏覽器緩存。
Session可以代表服務器與瀏覽器的一次會話過程,指從一個瀏覽器窗口打開到關閉的這個期間.也可以用於指一類用來在客戶端與服務器之間保持狀態的解決方案.
cookie機制採用的是在客戶端保持狀態的方案
session機制採用的是在服務器端保持狀態的方案。
同時由於在服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要藉助於cookie機制來達到保存標識的目的，但實際上還有其他選擇，比如說重寫 URL和隱藏表單域。
session比cookies更安全，比如把用戶名密碼保存在瀏覽器，下一個用戶登錄會暴露信息，session佔用資源也更多。其他不記得了
一般來說,登陸驗證信息,客戶的私人信息,如姓名,電話等,應該放在Session中.
Cookie則用於用戶登陸網站時的自動登陸以及類似"購物車"的處理.使用Cookie保存信息時最好通過加密形式來保存數據,同時是否保存登陸信息,需要由用戶自行選擇。
9.get，post區別
轉載自link
GET和POST是HTTP請求的兩種基本方法，最直觀的區別就是GET把參數包含在URL中，POST通過request body傳遞參數。
當你在面試中被問到這個問題，你的內心充滿了自信和喜悅，你輕輕鬆鬆的給出了一個“標準答案”：
GET在瀏覽器回退時是無害的，而POST會再次提交請求。
GET產生的URL地址可以被Bookmark，而POST不可以。
GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。
GET請求只能進行url編碼，而POST支持多種編碼方式。
GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。
GET請求在URL中傳送的參數是有長度限制的，而POST麼有。
對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。
GET比POST更不安全，因爲參數直接暴露在URL上，所以不能用來傳遞敏感信息。
GET參數通過URL傳遞，POST放在Request body中。（本標準答案參考自w3schools）
“很遺憾，這不是我們要的回答！”
GET和POST是什麼？HTTP協議中的兩種發送請求的方法。
HTTP是什麼？HTTP是基於TCP/IP的關於數據如何在萬維網中如何通信的協議。
HTTP的底層是TCP/IP。所以GET和POST的底層也是TCP/IP，也就是說，GET和POST本質上就是TCP鏈接，並無差別。但是由於HTTP的規定和瀏覽器/服務器的限制，導致他們在應用過程中體現出一些不同。
GET和POST還有一個重大區別，簡單的說：
GET產生一個TCP數據包；POST產生兩個TCP數據包。
長的說：
對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）；
而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。
因爲POST需要兩步，時間上消耗的要多一點，看起來GET比POST更有效。因此Yahoo團隊有推薦用GET替換POST來優化網站性能。但這是一個坑！跳入需謹慎。爲什麼？
GET與POST都有自己的語義，不能隨便混用。
據研究，在網絡環境好的情況下，發一次包的時間和發兩次包的時間差別基本可以無視。而在網絡環境差的情況下，兩次包的TCP在驗證數據包完整性上，有非常大的優點。
並不是所有瀏覽器都會在POST中發送兩次包，Firefox就只發送一次。
Socket通信流程
套接字是一種通信機制，憑藉這種機制，客戶/服務器系統的開發工作既可以在本地單機上進行，也可以跨網絡進行，Linux所提供的功能（如打印服務，ftp等）通常都是通過套接字來進行通信的，
套接字的創建和使用與管道是有區別的，因爲套接字明確地將客戶和服務器區分出來，套接字可以實現將多個客戶連接到一個服務器。
套接字是支持TCP/IP的網絡通信的基本操作單元，簡單的說就是通信的兩方的一種約定，用套接字中的相關函數來完成通信過程。應用層通過傳輸層進行數據通信時，TCP和UDP會遇到同時爲多個應用程序進程提供併發服務的問題。
簡單的舉例說明:Socket=Ip address+ TCP/UDP + port。
1. 面向連接的套接字Socket通信工作流程
爲了實現服務器與客戶機的通信,服務器和客戶機都必須建立套接字。服務器與客戶機的工作原理可以用下面的過程來描述。
1.服務器先用 socket 函數來建立一個套接字,用這個套接字完成通信的監聽。
2.用 bind 函數來綁定一個端口號和 IP 地址。因爲本地計算機可能有多個網址和 IP,每一個 IP 和端口有多個端口。需要指定一個 IP 和端口進行監聽。
3.服務器調用 listen 函數,使服務器的這個端口和 IP 處於監聽狀態,等待客戶機的連接。
4.客戶機用 socket 函數建立一個套接字,設定遠程 IP 和端口。
5.客戶機調用 connect 函數連接遠程計算機指定的端口。
6.服務器用 accept 函數來接受遠程計算機的連接,建立起與客戶機之間的通信。
7.建立連接以後,客戶機用 write 函數向 socket 中寫入數據。也可以用 read 函數讀取服務器發送來的數據。
8.服務器用 read 函數讀取客戶機發送來的數據,也可以用 write 函數來發送數據。
9.完成通信以後,用 close 函數關閉 socket 連接。
2.面向無連接的套接字Socket通信工作流程
無連接的通信不需要建立起客戶機與服務器之間的連接,因此在程序中沒有建立連接的過程。
進行通信之前,需要建立網絡套接字。服務器需要綁定一個端口,在這個端口上監聽接收到的信息。客戶機需要設置遠程 IP 和端口,需要傳遞的信息需要發送到這個 IP 和端口上。
原文鏈接：https://blog.csdn.net/weixin_42490152/article/details/99694247
瀏