網絡相關 數據庫

三次握手

客戶端發送帶SYN=1 seq=x的包給服務器端，進入syn_send狀態。
服務器端接收到客戶端的包后，檢查到SYN=1時表明對方要請求連接，服務器端同意連接即發送一個帶ACK=1，ack=x+1，SYN=1，seq=k的包給客戶端，進入syn_recv狀態。
客戶端接收檢查包信息。發送一個帶ACK=1,ack=k+1,seq=y+1的包給服務器，進入established確認狀態，服務器端接收后也進入確認狀態。

擴展：

1，為什么是三次而不是兩次？
因為兩次的話只能證明客戶端知道服務器端的接收和發送功能是正常的，不能說明服務端知道客戶端能有效的進行接收，服務端不確定客戶端是否同意它的連接請求。另一方面，如果只有兩次，假設客戶端發送了一次請求包，但由于某種原因延遲了到達服務端的時間，再發送了一次請求包，這時先到達服務端，服務端確認并發送確認包后由于客戶端沒有響應，而此時延遲的包到達了服務器端，服務器會認為之前的連接失敗，客戶端重新發送了請求，于是以此次連接為基礎雙方傳輸數據時，客戶端不承認這個連接，雙方進入等待狀態，直到連接結束。
3，TCP報文格式
| 源端口 |目的端口 |
確認號
確認序號
數據偏移4|保留6|URG|ACK|PSH|RST|SYN|FIN|窗口
校驗和|緊急指針
選項和填充

4，SYN網絡攻擊問題-典型的DDOS網絡攻擊（客戶端請求連接，服務器響應連接，客戶端一直未響應連接）
攻擊者偽造大量的SYN+不存在的ip的包發送給服務器，服務器響應，但因為是偽造的ip所以一直停留在SYN_RECEVED狀態。
解決：排查偽造包，輸入netstat -n -p TCP或netstat -nap | grep SYN_RECV可以查看大量停留在SYN_RECEVED狀態且隨機的ip。
注：也是由于這個原因，所以在確認連接前不連帶數據一起傳輸的原因，避免大量的偽造數據占據空間。

四次揮手

客戶端（FIN=1,seq=y）>FIN_WAIT1
服務端接收后發送ACK=1,ack=y+1進入closed_wait，客戶端接收到進入FIN_WAIT2
服務端傳輸數據結束后，發送FIN=1,seq=k,進入last_ack
客戶端接收檢查，發送ACK=1,ack=k+1回去后，進入TIME_WAIT狀態，等待2MSL時間 服務端接收到后雙方進入CLOSED狀態

http:

應用層的超文本傳輸協議，基于請求和響應的，無狀態的，?；趖cp/ip協議。提供一種用于發布和接收HTML頁面的方法。
http報文的格式分請求報文和響應報文。請求報文分請求行，首部行，實體主體，其中請求行包括了方法，url，版本，crlf回車換行。響應報文包括了狀態行，首部行，實體主體，狀態行包括了版本，狀態碼，狀態短語，crlf。

crlf攻擊：

通過header每一行后有一個crlf，header和body之間兩個crlf，通過在回車換行編碼%0d%0a來給header添加一些屬性，比如設置cookie，設置X_XSS_protected:0就可以對xss攻擊不攔截了。
crlf就是回車換行的意思，cr回車lf換行

http的特點：

1，無狀態，不會對客戶端的狀態進行存儲，沒有記憶功能
2，無連接，由于無狀態特征，每次請求都需要重新連接，如果客戶端向同一個資源進行請求，服務端不知道，都會做新的響應。
3，基于請求和響應。
4，明文傳輸，不能對對方進行身份認證，不能保證數據的完整性
5，簡單快速，靈活。

解決Http無狀態:1,增加cookie/session機制保存狀態
2，設置持久連接，在請求首部字段添加connection:keep-alive代表持久連接

https
是帶ssl加密協議的http。
特點：
1，內容加密。2，使用證書認證身份。3保護數據完整性，防止被冒充或篡改數據。

SSL，https是如何進行封裝的？

ssl連接過程： 1，客戶端請求連接到服務器的443端口，客戶端發送隨機數1和一組加密算法給服務端
2，服務端發送隨機數2和客戶端提供的加密算法（客戶端加密算法的子集）給客戶端響應握手信息
3，服務端發送證書信息給客戶端
4，客戶端檢查證書信息，通過就產生隨機數3（預主秘鑰），使用公鑰加密發送給服務器。
5，服務端使用私鑰解密該秘鑰。使用該秘鑰與之前協商的隨機數12組裝成會話秘鑰。（使用隨機數12是為了使每次的會話秘鑰都不同的概率增大）
6，客戶端使用之前協商的隨機數12，和秘鑰組裝成會話秘鑰，加密傳輸數據發送給服務端，檢驗是否正常。
7，服務端使用會話秘鑰加密信息也發送給客戶端。

補充：
服務端會使用哈希函數先摘要原文成一段密文，再使用秘鑰加密成數字簽名傳輸，對方會使用公鑰去解密，再把原來的原文使用哈希函數摘要，比對兩個數字摘要是否相同，不同表示文件內容被篡改了。

怎么保證保證服務器給客戶端下發的公鑰是真正的公鑰，而不是中間人偽造的公鑰呢？
解決：使用雙向驗證，在客戶端中內置服務器公鑰。服務器發送CA證書時要求返回公鑰。客戶端也發送內置的證書。雙方驗證比對是否相同且是否和內置的公鑰相同。

多路復用：使用同個tcp連接來多重并行進行請求和響應，提高處理速度

內連接、左連接、右連接

內連接就是滿足連接條件的元組查詢，外連接就是以一個表為基準表，除了滿足條件的還要不滿足條件的表的所有內容。
內連接：顯式使用關鍵字Inner join，例子：select * from a inner join b on a.id=b.id;
隱式的情況就是普通的聯表查詢，select * from a,b where a.id=b.id，可能會出現笛卡爾積。取決于where后面的條件在兩個表中是否是唯一性的。
與內連接對應的有外連接，外連接有三種：左連接，右連接，全外連接。
左連接：以左邊表，也就是from后的表為基礎，在它的基礎上找到右邊表滿足的對應起來，左邊表存在而右邊表不存在的右邊表的列字段補null。select * from a left join b on a.id=b.id。
右連接：同理。 right join
’全外連接：full join，把左邊表對應右邊表，右邊列不存在補空，右邊列對應左邊列，左邊列不存在補空，查詢出全部元組。比如：select * from a full join b on a.id=b.id;
一般，選擇合適的聯表查詢方式很重要，影響到數據的正確性。 當要查詢兩個表中相同的部分時可以用內連接； 當右邊表是左邊表的子集時可以用左連接；
當左邊表是右邊表的子集時可以用右連接； 當左邊表和右邊表彼此有交集且不是彼此的子集時，要查詢全部，使用full join。

補充：交叉連接，也叫笛卡爾積。顯示cross join，隱式，select * from a,b where…

進程線程、區別等。

進程：進程是一個具體獨立功能的程序在某個數據集合上的一次運行活動。它是系統資源分配和調度的基本單位。
線程：而線程是進程的實體，是比進程更小的獨立單位，它是cpu分配和調度的基本單位。
區別：1，進程擁有自己的內存單位，而線程沒有獨立的內存單位，但是同屬于一個進程下的線程可以共享進程的內存空間和資源。
2，線程不擁有系統資源，除了少部分的運行需要的棧，一組寄存器，程序計數器外。
3，線程是比進程更小的執行體，一個程序至少要有一個進程，一個進程至少要有一個線程。
4，進程比線程更健壯。當一個進程崩掉了，在保護模式下不會影響其他進程，而當一個線程崩掉了，整個進程也就死掉了。

狀態碼

1信息提示，接受的請求正在處理 2請求處理完畢 200成功 3重定向，分配了新的url，需要進行額外操作才能往下
301永久性重定向 302短暫性重定向 4客戶端錯誤 401請求報文語法錯誤 402未經許可，需進行http認證
403訪問權限限制拒絕訪問 404找不到請求的資源 5**服務端錯誤 500服務器處理請求時發生了錯誤
503由于服務器超負載或者停機處理導致無法處理請求。

linux搜索一個字符

grep -E -i ‘a|b’ 目錄路徑（-E表示“|”可以不用轉義符號，不需寫成“|”，-i表示忽略大小寫區分）找含有字符a或者b的行。
文件搜索，find -type -name ‘*.png’

總結

以上是生活随笔為你收集整理的网络 数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。