計算機基礎知識

這篇具有很好參考價值的文章主要介紹了計算機基礎知識。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點擊"舉報違法"按鈕提交疑問。

參考鏈接：https://blog.csdn.net/ChineseSoftware/article/details/123176978
https://www.cnblogs.com/8023-CHD/p/11067141.html
https://blog.csdn.net/qq_42033567/article/details/108088514

http與https的區(qū)別

HTTP 的URL以http:// 開頭，而HTTPS 的URL 以https:// 開頭
HTTP的默認端口是80，而HTTPS的默認端口是443
在OSI網(wǎng)絡模型中，HTTP工作于應用層，而HTTPS的安全傳輸機制工作在傳輸層
HTTP是明文傳輸，HTTPS 在 HTTP 的基礎上加入了 SSL 協(xié)議，SSL 依靠證書來驗證服務器的身份，并為瀏覽器和服務器之間的通信加密。
HTTP的連接很簡單，是無狀態(tài)的。HTTPS是由SSL+HTTP構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比HTTP安全。

Linux常用命令


cd 命令切換目錄
ls 命令查看當前目錄下的文件
	-l:列出長數(shù)據(jù)串，包含文件的屬性與權限數(shù)據(jù)等 
	-a:列出全部的文件，連同隱藏文件（開頭為.的文件）一起列出來（常用）
pwd 當前目錄的絕對路徑 
touch 創(chuàng)建文件
mkdir 創(chuàng)建文件夾
mv 移動文件、目錄
rm 用于刪除文件或目錄
vim 用于文件編輯
cat 用于查看文本文件內容
tar 對文件進行壓縮與解壓縮 壓縮：tar -zcf 解壓縮：tar -zxf
kill 終止進程
chmod 改變文件權限 r：讀權限 w：寫權限 x：可執(zhí)行權限 u：用戶 g：同組用戶 o:其他用戶 a：所有用戶
chmod xxx 文件名稱
每一位分別表示不同類的權限，每一位的范圍為0-7，表示讀寫執(zhí)行的權限。

tcp和udp的區(qū)別

連接方面，TCP是面向連接的，UDP是無連接的。
TCP是面向字節(jié)流的，發(fā)送數(shù)據(jù)時會將數(shù)據(jù)分解為多個小的數(shù)據(jù)報文進行發(fā)送；UDP是基于數(shù)據(jù)報的，發(fā)送數(shù)據(jù)時會直接打上UDP頭將整個報文發(fā)送出去。
TCP只支持一對一通訊；而UDP支持一對一、一對多、多對一、多對多通訊。
TCP要求實時性低、準確度高；UDP要求實時性高、準確度低。
TCP頭部20-60字節(jié)，UDP頭部8個字節(jié)。
TCP提供可靠的傳輸服務，通過TCP連接傳輸?shù)臄?shù)據(jù)，無差錯、不重復、按序到達；UDP盡最大努力進行交付，不保證可靠交付。
基于TCP的應用層協(xié)議有：SMTP（簡單郵件傳輸協(xié)議）、TELNET（遠程登錄服務協(xié)議）、HTTP（超文本傳輸協(xié)議）、FTP（文件傳輸協(xié)議）。
基于UDP的應用層協(xié)議：NFS（網(wǎng)絡文件系統(tǒng)）、SNMP（簡單網(wǎng)絡管理協(xié)議）、DNS（主域名稱系統(tǒng)）、TFTP（簡單文件傳輸協(xié)議）。

cookie和session區(qū)別

cookie通過在客戶端記錄信息確定用戶身份，session通過在服務器端記錄信息確定用戶身份。
cookie不是很安全，考慮安全應當使用session。
因為session會在一定時間保存在服務器上，當訪問增多，會比較占用服務器性能，考慮到減輕服務器性能方面，應當使用cookie。
單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
可以考慮將登陸信息等重要信息存放為 session，其他信息如果需要保留，可以放在 cookie 中。

進程和線程的區(qū)別

1.根本區(qū)別：進程是操作系統(tǒng)進行資源分配的最小單位，線程是操作系統(tǒng)進行任務調度的最小單位。
2.從屬關系不同：進程中包含了線程，線程屬于進程。
3.開銷不同：進程的創(chuàng)建、銷毀和切換的開銷都遠大于線程。
4.擁有資源不同：每個進程都有自己的內存空間，一個進程中的線程會共享這些內存空間。
5.CPU利用率不同：進程的CPU利用率較低，因為上下文切換開銷較大，而線程的CPU利用率高，上下文的切換速度快。
6.操縱者不同：進程的操縱者一般是操作系統(tǒng)，線程的操縱者一般是編程人員。

線程有哪幾種狀態(tài)

線程通常都有5種狀態(tài)，創(chuàng)建、就緒、運行、阻塞和死亡。
創(chuàng)建： 在生成線程對象，并沒有調用該對象的start方法，這時線程處于創(chuàng)建狀態(tài)。
就緒： 當調用了線程對象的start方法后，該線程就進入了就緒狀態(tài)，當調用了線程對象的start方法后，該線程就進入了就緒狀態(tài)。此時線程調度程序還沒有把該線程設置為當前線程。當線程從等待或者睡眠中回來后也會處于就緒狀態(tài)。
運行： 線程調度程序將處于就緒狀態(tài)的線程設置為當前線程，此時線程就進入了運行狀態(tài)，開始執(zhí)行run函數(shù)中的代碼。
阻塞： 線程正在運行時，因為等待某個資源被暫停進入阻塞狀態(tài)。sleep、suspend等方法都能導致線程阻塞。
死亡： 如果一個線程的run方法執(zhí)行結束，該線程就會死亡。

http的三次握手和四次揮手

三次握手

計算機基礎知識

第一次握手：客戶端發(fā)送一個SYN報文，并指明客戶端的初始化序列號，此時客戶端處于SYN-SENT狀態(tài)。
第二次握手：服務器收到客戶端的SYN報文后，會以自己的SYN報文作為應答，也指定自己的初始化序列號，將客戶端的seq+1作為ack的值，表示自己收到了客戶端的seq，并請求下一個seq，此時服務器處于SYN-RCVD狀態(tài)。
第三次握手：客戶端收到SYN報文后，會發(fā)送一個ACK報文，將ack設為服務器的seq+1，表示已經(jīng)收到服務器的SYN報文，并發(fā)送下一個seq，此時客戶端初一ESTABLISHED狀態(tài)，服務器收到ACK報文后，也處于ESTABLISHED狀態(tài)，此時，雙方已建立起了連接。
為什么要三次握手？
通過三次握手可以保證雙方的發(fā)送和接收能力正常，確保與列好同步，以及防止舊的失效連接請求產(chǎn)生誤解，從而建立可靠的鏈接。
確認雙方的發(fā)送和接收能力：第一次握手客戶端發(fā)送SYN報文段到服務器，服務器接收到SYN報文段后，確認客戶端的發(fā)送能力和自己的接收能力正常。
確保客戶端和服務器的序列號同步：在第二次握手時，服務器發(fā)送了帶有SYN/ACK標志的報文段，其中ACK確認號字段的值為客戶端的初始序列號加1，同時，服務器也選擇了自己的初始序列號。這樣，客戶端和服務器都知道對方的初始序列號，并可以同步它們的序列號。
防止已失效的連接請求報文段產(chǎn)生連接：考慮這樣一種情況，客戶端發(fā)送了一個連接請求報文段，但因網(wǎng)絡延遲等原因導致該報文段長時間滯留，過了一段時間后，客戶端重新發(fā)送了一個新的連接請求報文段并成功建立連接。此時，滯留的舊報文段可能會到達服務器，如果只進行兩次握手，服務器會認為這是一個新的連接請求并建立連接，而實際上客戶端可能已經(jīng)關閉了該連接。通過三次握手，可以讓服務器確認客戶端對連接的真實意圖。

http的四次握手

計算機基礎知識

第一次揮手：客戶端會發(fā)送一個FIN報文，報文會指定一個序列號，此時客戶端處于FIN-WAIT1狀態(tài)。
第二次揮手：服務端收到FIN報文后，會發(fā)送ACK報文，并且把ack等于客戶端序列值+1表示已經(jīng)收到客戶端的FIN報文了，此時服務端處于CLOSE-WAIT狀態(tài)?？蛻舳耸盏椒斩说腁CK報文后，進入FIN-WAIT2。
第三次揮手：服務端傳輸完剩余數(shù)據(jù)后，服務端想斷開連接，會發(fā)送FIN報文，且指定一個序列號，此時服務端處于LAST-ACK狀態(tài)。
第四次揮手：客戶端收到FIN后，發(fā)送ACK報文進行應答，seq=服務器的ack，ack=服務器的seq+1，此時客戶端處于TIME-WAIT狀態(tài)，需要過一陣子以確保服務器收到自己的ACK報文進入CLOSE狀態(tài)，服務器收到ACK報文后，也進入CLOSE狀態(tài)。

為什么要四次揮手？

為了保證在最后斷開的時候，客戶端能夠發(fā)送最后一個ACK報文段能夠被服務器接收到。如果客戶端在收到服務器給它的斷開連接的請求之后，回應完服務器就直接斷開連接的話，若服務器沒有收到回應就無法進入CLOSE狀態(tài)，所以客戶端要等待兩個最長報文段壽命的時間，以便于服務器沒有收到請求之后重新發(fā)送請求。
防止“已失效的連接請求報文”出現(xiàn)在連接中，在釋放連接的過程中會有一些無效的滯留報文，這些報文在經(jīng)過2MSL的時間內就可以發(fā)送到目的地，不會滯留在網(wǎng)絡中。這樣就可以避免在下一個連接中出現(xiàn)上一個連接的滯留報文了。

為什么需要接收方最后等待2MSL
1MSL表示一個1個最長報文段的壽命。
接收方等待最后一次ack+重發(fā)的第三次釋放連接請求到達發(fā)送方的時間<=2MSL，因此需要等待2MSL。
本質原因是網(wǎng)絡是不可靠的，所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文。如果發(fā)送方的最后一次ack沒有被接收方收到的話，那么接收方會進行重傳第三次的釋放連接請求，TIME_WAIT就是為了在這種情況下重發(fā)丟失了的ack報文。

TCP為什么是可靠的
可靠傳輸就是通過TCP連接傳送的數(shù)據(jù)是沒有差錯、不會丟失、不重復并且按序到達的。TCP通過序列號、檢驗和、確認應答信號、重發(fā)機制、連接管理、窗口控制、流量控制、擁塞控制一起保證TCP傳輸?shù)目煽啃浴?span toymoban-style="hidden">文章來源地址http://www.zghlxwxcb.cn/news/detail-498538.html

確認應答 （1）發(fā)送端每次發(fā)送數(shù)據(jù)時，TCP就給每個數(shù)據(jù)包分配一個序列號并且在一個特定的時間內等待接收端對分配的這個序列號進行確認，如果發(fā)送端在一個特定時間內沒有收到接收端的確認，則發(fā)送端會重傳此數(shù)據(jù)包。（2）接收端利用序列號對接收的數(shù)據(jù)進行確認，以便檢測對方發(fā)送的數(shù)據(jù)是否有丟失或者亂序等，接收端一旦收到已經(jīng)順序化的數(shù)據(jù)，它就將這些數(shù)據(jù)按正確的順序重組成數(shù)據(jù)流并傳遞到高層進行處理。
超時重傳 TCP協(xié)議要求在發(fā)送端每發(fā)送一個報文段，就啟動一個定時器并等待確認信息；接收端成功接收新數(shù)據(jù)后返回確認信息。若在定時器超時前數(shù)據(jù)未能被確認，TCP就認為報文段中的數(shù)據(jù)已丟失或損壞，需要對報文段中的數(shù)據(jù)重新組織和重傳。發(fā)送方?jīng)]有接收到響應的ACK報文原因可能有兩點：（1）數(shù)據(jù)在傳輸過程中由于網(wǎng)絡原因等直接全體丟包，接收方根本沒有接收到。（2）接收方接收到了響應的數(shù)據(jù)，但是發(fā)送的ACK報文響應卻由于網(wǎng)絡原因丟包了。
擁塞控制 慢啟動、擁塞避免、快重傳、快恢復
流量控制 如果發(fā)送方把數(shù)據(jù)發(fā)送得過快，接收方可能會來不及接收，這就會造成數(shù)據(jù)的丟失。所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來得及接收。利用滑動窗口機制可以很方便地在TCP連接上實現(xiàn)對發(fā)送方的流量控制。