一、 反射/序列化/拷貝

1. 反射

//反射主要是指程序可以訪問、檢測和修改它本身狀態(tài)或行為的一種能力
//在Yaml數(shù)據(jù)驅(qū)動自動化框架比較適用，能獲取到當(dāng)前的類名及方法名
import java.lang.reflect.*;

public class ReflectionExample {
    public static void main(String[] args) throws Exception {
        // 獲取當(dāng)前類的 Class 對象
        Class<?> currentClass = ReflectionExample.class;

        // 獲取當(dāng)前方法的 Method 對象
        Method currentMethod = currentClass.getDeclaredMethod("main", String[].class);

        // 獲取類名和方法名
        String className = currentClass.getName();
        String methodName = currentMethod.getName();

        System.out.println("當(dāng)前類名：" + className);
        System.out.println("當(dāng)前方法名：" + methodName);
    }
}

2. 序列化

序列化是指將一個對象抓換為字節(jié)流在網(wǎng)絡(luò)上傳輸?shù)椒?wù)器，服務(wù)器對其進(jìn)行反序列化
可以使用 Serializable 接口來標(biāo)記一個類可以被序列化

3. 動態(tài)代理

Java 動態(tài)代理是一種在運行時生成代理類的機制，
允許你在不事先知道具體代理類的情況下創(chuàng)建代理對象。
動態(tài)代理通常用于在代理模式中，通過代理對象來控制對實際對象的訪問，
并可以在代理的前后添加一些額外的邏輯。


動態(tài)代理的用途包括：

日志記錄：在方法調(diào)用前后添加日志記錄。
性能監(jiān)控：統(tǒng)計方法調(diào)用的耗時。
事務(wù)管理：在方法調(diào)用前后開啟、提交或回滾事務(wù)。
權(quán)限控制：在方法調(diào)用前檢查用戶權(quán)限。
緩存控制：在方法調(diào)用前從緩存中獲取數(shù)據(jù)，或在方法調(diào)用后將結(jié)果緩存起來。

4. 深拷貝和淺拷貝

1. 淺拷貝
只復(fù)制了對象的引用地址，2個引用指向同一個內(nèi)存地址，在其中一個變化后，另一個的也會同時變化。
2. 深拷貝
既復(fù)制了內(nèi)存地址，也復(fù)制了引用地址；變化不會影響其他

二、Http相關(guān)

1. Session與Cookie

1. Session存儲在服務(wù)端，Cookie存儲在用戶本地瀏覽器
2. Session更加安全，cookie可能會存在被篡改的風(fēng)險
3. Session存儲比較大的數(shù)據(jù)，而Cookie相對比較小，不超過4kb

Session的工作原理：存儲在服務(wù)器的Session可以理解是一個Map。
Session是key，里面還有其他用戶信息是value。
用戶請求的時候拿Cookie包裝了sessionID換取其他信息

2. 如何避免sql注入

攻擊原理：在瀏覽器通過偽造，注入一段sql達(dá)到查詢/修改數(shù)據(jù)庫，達(dá)到攻擊目的
避免：
1. 使用參數(shù)化查詢
2. 對輸入的內(nèi)容進(jìn)行(正則/字符串)過濾
3. 使用 Web 應(yīng)用防火墻（WAF）來檢測和阻止惡意 SQL 注入攻擊。

3. XSS(跨站腳本攻擊)

原理：用戶在瀏覽網(wǎng)頁的時候，通過Xss注入HTML代碼，當(dāng)用戶瀏覽或者輸入某些內(nèi)容的時候自動調(diào)用，
從而獲取當(dāng)前網(wǎng)頁用戶的消息
避免：對輸入/URL進(jìn)行過濾，對輸出進(jìn)行編碼。

4.?CSRF(跨站網(wǎng)站攻擊)?

原理：
給用戶提供和目標(biāo)網(wǎng)站類似的網(wǎng)站/放置惡意鏈接，用戶在登錄狀態(tài)下點擊某功能。
導(dǎo)致調(diào)用鏈其他鏈接，例如：修改密碼，轉(zhuǎn)賬等

避免：
1. 敏感操作短信驗證碼
2. CSRF  token
    1). CSRF Token 是一種用于防止 CSRF 攻擊的機制。網(wǎng)站會在用戶登錄后，為用戶生成一個隨機的 CSRF Token，并將其存儲在用戶的會話中或者通過 Cookie 返回給用戶。
    2). 在進(jìn)行敏感操作（如修改密碼、更改賬戶信息）時，網(wǎng)站會要求用戶提供這個 CSRF Token。用戶在提交請求時，需要將 CSRF Token 隨請求一同發(fā)送到服務(wù)器。
    3). 服務(wù)器會驗證提交的 CSRF Token 是否與會話中或者 Cookie 中的 Token 匹配，如果匹配則說明請求是合法的，否則拒絕請求。

三、HTTP狀態(tài)及傳輸方式

1. 301與302redirect(重定向)

301 永久重定向
302 暫時重定向

2.?forward 和 redirect 的區(qū)別

1. forward
直接轉(zhuǎn)發(fā) - 客戶端/瀏覽器發(fā)出1次請求，A請求B，B請求C。最后C把信息轉(zhuǎn)發(fā)給了A
2. redirect
間接轉(zhuǎn)發(fā) - 客戶端/瀏覽器發(fā)出2次請求，A請求B，不通并讓請求C，A請求了C

3. tcp和udp

1. TCP面向連接，UDP不面向連接。TCP需要3次握手和4次揮手
2. TCP是穩(wěn)定傳輸，適合小流量，UDP是可能存在丟包，用于大文件傳輸/在線游戲等

4.?OSI 的七層模型

OSI（Open Systems Interconnection）模型是一個網(wǎng)絡(luò)協(xié)議的參考模型，將網(wǎng)絡(luò)通信劃分為七個層次，每個層次負(fù)責(zé)不同的功能。以下是 OSI 模型的七層以及通俗易懂的例子：

1. 物理層（Physical Layer）：

負(fù)責(zé)傳輸原始比特流，處理物理連接、電壓、光信號等。
例子：以太網(wǎng)的電纜、光纖、網(wǎng)卡等。

2. 數(shù)據(jù)鏈路層（Data Link Layer）：

提供點對點的可靠數(shù)據(jù)傳輸，將比特流分組成幀，并進(jìn)行錯誤檢測和糾正。
例子：以太網(wǎng)幀、Wi-Fi 數(shù)據(jù)幀。

3. 網(wǎng)絡(luò)層（Network Layer）：

負(fù)責(zé)尋址和路由，將數(shù)據(jù)包從源主機傳輸?shù)侥繕?biāo)主機。
例子：IP 地址、路由器。

4. 傳輸層（Transport Layer）：

提供端到端的數(shù)據(jù)傳輸，負(fù)責(zé)分段、重組和流量控制。
例子：TCP、UDP。

5. 會話層（Session Layer）：

管理不同應(yīng)用之間的會話，建立、維護(hù)和終止連接。
例子：會話管理、連接控制。
6. 表示層（Presentation Layer）：

負(fù)責(zé)數(shù)據(jù)的格式轉(zhuǎn)換、加密、解密等，確保應(yīng)用之間的數(shù)據(jù)能夠正確解釋。
例子：數(shù)據(jù)壓縮、加密解密。

7. 應(yīng)用層（Application Layer）：

最上層，提供用戶應(yīng)用程序的接口，處理用戶數(shù)據(jù)和網(wǎng)絡(luò)通信。
例子：Web 瀏覽器、電子郵件客戶端、文件傳輸協(xié)議（FTP）。

5.?HTTP常見狀態(tài)碼

200 OK： 請求正常
204 No Content：服務(wù)器處理了請求，但是木有任何返回
400 Bad Request：用戶發(fā)送了請求，但是服務(wù)器無法處理；不認(rèn)識看不懂
401 Unauthorized：認(rèn)證失敗，鑒權(quán)過期等
403 Forbidden：請求被拒絕
404 Not Found：請求的鏈接有問題可能，找不到
500 Internal Server Error：服務(wù)器異常了
503 Service Unavailable：服務(wù)器暫時無法處理請求，可能是維護(hù)
504 Service Timeout：服務(wù)器從上游接收消息超時

6. HTTP HTTPS區(qū)別

1. 安全性：https是基于加密傳輸，http明文傳輸
2. 證書：https的網(wǎng)站是基于證書認(rèn)證
3. 端口：http-80，https-443
4. 使用場景：http網(wǎng)站文本查看等，https登錄、支付等

7. HTTPS傳輸過程

1. 客戶端請求服務(wù)端
2. 服務(wù)端收到請求，發(fā)送證書及公鑰
3. 客戶端收到證書后驗證，查看過期時間等等。
    異常提示
    正常繼續(xù)，生成隨機數(shù)，隨機數(shù)通過公鑰加密傳輸給服務(wù)端
4. 服務(wù)端收到請求后，解密獲取到私鑰，并把數(shù)據(jù)混合在一起通過加密方式傳輸?shù)娇蛻舳?5. 客戶端收到消息，通過私鑰解密，獲取到了信息

8. 三次握手

首先明確過程：
1. 客戶端發(fā)送請求鏈接
2. 服務(wù)端確認(rèn)可以連接，發(fā)送請求和客戶端連接的請求
3. 客戶端收到后發(fā)送給服務(wù)器確認(rèn)可以連接


每個請求類別的字段：
1. 請求需要有SYN標(biāo)志位，默認(rèn)1，每個鏈接都有數(shù)據(jù)包，數(shù)據(jù)包報文號seq
2. 每個確認(rèn)都有ACK的標(biāo)志位，默認(rèn)1，確認(rèn)數(shù)據(jù)包ack=上一次的seq+1(表示我收到了初始序列seq=x的報文)；
確認(rèn)也需要有自己的數(shù)據(jù)包報文號seq=[具體情況]


具體過程：
第一次握手：客戶端發(fā)送和服務(wù)端連接的請求：SYN=1，seq=x
第二次握手：服務(wù)端發(fā)送確認(rèn)和客戶端連接，并且發(fā)送服務(wù)端和客戶端建立連接的請求
           ACK=1，ack=x+1；       SYN=1，seq=y
第三次握手：客戶端發(fā)送確認(rèn)可以連接的請求
            ACK=1， ack=y+1，seq=x+1

9. 為什么要三次握手，2次行不行

廢話文學(xué)，特喵的當(dāng)然不行啊?。?！

2次握手可能會導(dǎo)致服務(wù)端消費+建立過期的會話

栗子(假設(shè)只有2次握手的連接)：
1. 客戶端發(fā)送了一個數(shù)據(jù)包報文號seq=x的連接請求，但是由于網(wǎng)絡(luò)等等原因，導(dǎo)致服務(wù)端沒有收到。
    也導(dǎo)致了客戶端一直沒有收到服務(wù)端確認(rèn)建立連接的請求
2. 客戶端不得已再次發(fā)送seq=y請求，這次網(wǎng)絡(luò)順暢，服務(wù)端收到后，發(fā)送了確認(rèn)可以連接的請求。成功建立連接. 數(shù)據(jù)傳輸完成之后斷開連接
3. 然而過了一會服務(wù)端收到了seq=x的請求數(shù)據(jù)，服務(wù)端很高興又能和他建立連接了，然后建立了一個過期的請求鏈接

?9. 四次揮手

1. 請求結(jié)束會有FIN，回應(yīng)結(jié)束是ACK，ack回復(fù)的時候會有，seq是請求的數(shù)據(jù)報文號

過程：
客戶端發(fā)送結(jié)束的請求：FIN=1，seq=u
服務(wù)端回應(yīng)已收到斷開的請求，此時服務(wù)器還是可以繼續(xù)發(fā)送：ACK=1，ack=u+1，seq=v
服務(wù)端數(shù)據(jù)傳輸完成之后，發(fā)送請求斷開的：FIN=1，seq=w      ACK=1，ack=u+1
客戶端收到斷開請求，并且做回應(yīng)：ACK=1，ack=w+1， seq=u+1

?文章來源地址http://www.zghlxwxcb.cn/news/detail-665476.html

到了這里，關(guān)于Java基礎(chǔ)八 - HTTP相關(guān)/Cookie/Session/網(wǎng)絡(luò)攻擊的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！