http --- http與https相關概念小結

網絡協議

參考

HTTP的特性

  • HTTP協議構建于TCP/IP協議之上,是一個應用層協議,默認端口是80
  • HTTP是無連接無狀態的

HTTP報文

請求報文

HTTP協議是以ASCII碼傳輸,建立在 TCP/IP 協議之上的應用層規范。規范把HTTP請求分為三個部分:狀態行、請求頭、消息主體。

<method> <request-URL> <version>
<headers><entity-body>

HTTP定義了與服務器交互的不同方法,最基本的方法有4種:GET 、POST、PUT、DELETE

  • GET: 查找服務器中的數據,不會修改和增加數據,不會影響資源的狀態

    • GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 1.7.6)
Gecko/20050225	Firefox/1.0.1
Connection: Keep-Alive

  • POST: 新增資源

    • POST / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Window NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alivesex=man&name=Professional

【注意】:

  • GET可提交的數據量受到URL長度限制.(HTTP協議內并未對其進行限制,這個限制是特定的瀏覽器及服務器對它的限制)

  • 理論上講,POST是沒有大小限制的,HTTP協議規范也沒有進行大小限制,處于安全考慮,服務器軟件在實現時會做一定限制

  • GET的數據請求是在URL中、POST的數據請求在HTTP包里

POST提交數據的方式

服務器端通常是根據請求頭(headers)中的Content-Type字段來獲知請求中的消息主體是用何種方式編碼,再對主體進行解析。所以說到POST提交數據方案,包含了Content-Type和消息主體編碼方式兩部分。

  • application/x-www-form-urlencoded

    • 最常見的POST數據提交方式。瀏覽器的原生<form>表單,如果不設置entype屬性,那么最終就會以application/x-www-form-urlencoded方式提交數據

  • multipart/form-data

    • 另外一個常見的POST數據提交方式。我們使用表單上傳文件時,必須讓<form>表單的entype等于multipart/form-data,看下面的栗子:

    • POST http://www.example.com HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/pngPNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA

上面首先生成了boundary用于分割不同的字段,為了避免與正文內容重復,boundary很長很復雜。然后Content-Type里指明了數據是以multipart/form-data來編碼,本次請求的boundary是什么內容

響應報文

HTTP響應報文與HTTP請求類似,HTTP響應也是由3個部分構成,分別是：

  • 狀態行
  • 響應頭(Response Header)
  • 響應正文

狀態行由協議版本、數字形式的狀態碼、及相應的狀態描述,各元素之間以空格分隔

常見的狀態碼有以下幾種:

  • 200 OK: 客戶端請求成功
  • 301 Moved Permanently: 請求永久重定向
  • 302 Moved Temporarily: 請求臨時重定向
  • 304 Not Modified: 文件未修改,可以直接使用緩存的文件
  • 400 Bad Request: 客戶端的請求有語法錯誤,不能被服務器所理解
  • 401 Unauthorized: 請求未授權.這個狀態碼必須和WWW-Authenticate報頭域一起使用
  • 403 Forbidden: 需要客戶端提供驗證的信息
  • 404 Not Found: 客戶端請求的資源并不存在
  • 500 Internal Server Error: 服務器發生錯誤,與客戶端無關
  • 503 Service Unavailable: 服務器當前不能處理客戶端的請求,在一段時間后,服務器可能會恢復正常

[一個HTTP響應的栗子]

HTTP/1.1 200 OKServer:Apache Tomcat/5.0.12
Date:Mon,60ct2003 13:23:42 GMT
Content-Length:112<html>...

條件GET

HTTP條件GET是HTTP協議為了減少不必要的帶寬浪費,提出的一種方案

  1. HTTP條件GET使用的時機?

    客戶端之間已經訪問過某網站,并打算再次訪問該網站

  2. HTTP條件GET使用的方法?

    客戶端向服務器發送一個包詢問是否在上一次訪問網站的時間后更改了頁面,如果服務器沒有更新,顯然不需要把整個網頁傳給客戶端,客戶端只要使用本地緩存即可,如果服務器對照客戶端給出的時間已經更新了客戶端請求的網頁,則發送這個更新了的網頁給用戶

    下面是一個具體的發送接受報文示例:

    客戶端發送請求:

    GET / HTTP/1.1
Host: www.sina.com.cn:80
If-Modified-Since: Thu, 4 Feb 2010 20:39:13 GMT
Connection: Close

    第一次請求時,服務器端返回請求數據,之后的請求,服務器根據請求中的If-Modified-Since字段判斷響應文件是否更新:

    • 否: 服務器返回一個304 Not Modified響應,告訴瀏覽器請求的資源在瀏覽器上沒有更新,可以使用上次的文件
    HTTP/1.0 304 Not Modified
Date: Thu, 04 Feb 2010 12:38:41 GMT
Content-Type: text/html
Expires: Thu, 04 Feb 2010 12:39:41 GMT
Last-Modified: Thu, 04 Feb 2010 12:29:04 GMT
Age: 28
X-Cache: HIT from sy32-21.sina.com.cn
Connection: close
    • 是: 服務器正常返回

持久連接

  • 普通模式: HTTP采用請求/應答模式,當非Keep-Alive模式時,每個請求/應答 客戶和服務器都要新建一個連接,完成之后立即斷開連接
  • 持久連接: 當使用Keep-Alive模式時,Keep-Alive功能使客戶端到服務器的連接持續有效,當出現對服務器的后續請求時,Keep-Alive功能避免了建立或者重寫建立連接

在HTTP 1.0版本中,并沒有官方的標準來規定Keep-Alive如何工作,因此實際上它是被附加到HTTP 1.0 協議上,如果客戶端瀏覽器支持Keep-Alive,那么就在HTTP請求頭中添加一個Connection: Keep-Alive,當服務器收到附帶Connection:Keep-Alive的請求時,它也會在響應頭中添加一個同樣的字段來使用Keep-Alive.這樣一來,客戶端和服務器之間的HTTP連接就會被保持,不會斷開(超過Keep-Alive規定的時間,意外斷電等情況除外),當客戶端發送另一個請求時,就使用這條已經建立的連接

在HTTP 1.1 版本中,默認情況下所有連接都被保持,如果假如Connection: close才關閉.目前大部分瀏覽器都使用 HTTP 1.1 協議,也就是說默認都會發起Keep-Alive的連接請求了，所以是否能完成一個完整的Keep-Alive連接就看服務器設置情況

注意:

  • HTTP Keep-Alive 簡單說就是保持當前的TCP連接,避免了重新建立連接
  • HTTP長連接不可能一直保持,例如Keep-Alive: timeout=5, max=100,表示這個TCP通道可以保持5秒,最多接收100次請求就斷開
  • HTTP是一個無狀態協議,這意味著每個請求都是獨立的,Keep-Alive沒能改變這個結果。另外,Keep-Alive也不能保證客戶端和服務器之間的連接一定是活躍的,在HTTP 1.1版本中也如此.唯一能保證的就是當連接被關閉時你能得到一個通知,所以不應該讓程序依賴于Keep-Alive的保持連接特性,否則會有意想不到的后果
  • 使用長連接,客戶端、服務端怎么知道本次傳輸結束呢?兩部分:
    • 判斷傳輸數據是否到達了Content-Length指示的大小
    • 動態生成文件沒有Content-Type,它是分塊傳輸(chunked),這時候就要根據chunked編碼來判斷,chunked編碼的數據在最后有一個空的chunked塊,表明本次傳輸數據結束

Transfer-Encoding

Transfer-Encoding是一個用來標示HTTP報文傳輸格式的頭部值.盡管這個取值理論上可以有很多,但是當前的HTTP規范里實際上只定義了一種傳輸取值(chunked)

如果一個HTTP消息(請求消息或應答消息)的Transfer-Encoding消息頭的值為chunked,那么,消息體由數量未定的塊組成,并以最后一個大小為0的塊為結束

每一個非空的塊都以該塊包含數據的字節數(字節數以十六進制表示)開始,跟隨一個回車換行(CRLF),然后是數據本身,最后塊CRLF結束.在一些實現中,塊大小和CRLF之間填充有白空格(0x20)

最后一塊是單行,由塊大小(0),一些可選的填充白空格,以及CRLF。最后一塊不再包含任何數據,但是可以發送可選的尾部,包含消息頭部。消息最后以CRLF結尾

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked25
This is the data in the first chunk1A
and this is the second one0

注意:

  • chunked和multipart兩個名詞在意義上有類似的地方,不過在HTTP協議當中,這兩個概念則不是一個類別的。multipart是一種Content-Type,標示HTTP報文內容的類型,而chuncked是一種傳輸格式,標示報頭將以何種方式進行傳輸
  • chuncked傳輸不能事先知道內容的長度,只能靠最后的空chunk塊來判斷,因此對于下載請求來說,是沒有辦法事先進度的。在瀏覽器和下載工具中,偶爾我們也會看到有些文件是看不到下載進度的,即采用chunked方式進行下載
  • chunked的優勢在于,服務器端可以邊生成內容邊發送,無需事先生成全部的內容。HTTP/2不支持 Transfer-Encoding: chuncked, 因為HTTP/2 有自己的 streaming傳輸方式

HTTP Pipelining(HTTP 管線化)

默認情況下HTTP協議中每個傳輸層連接只能承載一個HTTP請求和響應,瀏覽器會收到上一個請求的響應之后,再發送下一個請求。在使用持久連接的情況下,某個連接上消息的傳遞類似于:請求1 -> 響應1 -> 請求2 -> 響應2 -> 請求3 -> 響應3

HTTP Pipelining(管線化)是將多個HTTP請求整批提交的技術,在傳輸過程中不需要等待服務器的回應。使用HTTP Pipelining技術之后,某個連接上的消息變成了類似這樣請求1 -> 請求2 -> 請求3 -> 響應1 -> 響應2 -> 響應3

注意下面幾點:

  • 管線化機制通過持久連接(persistent connection)完成,僅 HTTP/1.1 支持此技術(HTTP/1.0 不支持)
  • 只有GET和HEAD請求可以進行管線化,而POST則有所限制
  • 初次創建連接時不應啟動管線機制,因為對方(服務器)不一定支持HTTP/1.1版本的協議
  • 管線化不會影響響應到來的順序
  • HTTP/1.1要求服務器端支持管線化,但并不要求服務器也對響應進行管線化處理,只是要求對于管線化的請求不失敗即可
  • 由于上面提到的服務器端問題,開啟管線化很可能并不會帶來大幅度的性能提升,而且很多服務器端和代理程序對管線化的支持并不好,因此現代瀏覽器和Chrome和Firefox默認并未開啟管線化支持

會話跟蹤

  1. 什么是會話

    客戶端打開與服務器的連接發出請求到服務器響應客戶端請求的全過程稱之為會話

  2. 什么是會話跟蹤

    是對同一個用戶服務器的連續的請求和接受響應的監視

  3. 為什么需要會話跟蹤

    瀏覽器與服務器之間的通信是通過HTTP協議進行的,而HTTP協議是"無狀態"協議,它不能保存客戶的信息,即一次響應完成之后連接就斷開了,下一次的請求需要重新連接,這樣就需要判斷是否是同一個用戶,所以才會有會話跟蹤技術來實現這種要求

【會話跟蹤常用的方法】

  • URL重寫:
    • URL是Web上特定頁面的地址,URL重寫的技術就是在URL結尾添加一個附加數據以標識該會話,把會話ID通過URL的信息傳遞過去,以便在服務器端進行識別不同的用戶
  • 隱藏表單域
    • 將會話ID添加到HTML表單元素中提交到服務器,此表單元素并不在客戶端顯示
  • Cookie
    • Cookie是Web服務器發送給客戶端的一小段信息,客戶端請求時可以讀取該信息發送到服務器端,進而進行用戶的識別。對于客戶端的每個請求,服務器都會將Cookie發送到客戶端,在客戶端可以進行保存,以便下次使用.
    • 客戶端可以采用兩種方式來保存這個Cookie對象,一種方式是保存在客戶端內存中,稱為臨時Cookie,瀏覽器關閉后這個Cookie對象將消失。另外一種方式是保存在客戶機的磁盤上,稱為永久Cookie。以后客戶端只要訪問該網站,就會將這個Cookie再次發送到服務器上,前提是這個Cookie在有效期內,這樣就實現了對客戶的跟蹤
    • Cookie是可以被客戶端禁用的
  • Session
    • 每個客戶都有一個不同的session,各個用戶之間是不能共享的,是每個用戶所獨享的,在session中可以存放信息
    • 在服務器端會創建一個session對象,產生一個sessionID來標識這個session對象,然后將這個sessionID放入到Cookie中發送到客戶端,下一次訪問時,sessionID會發送到服務器,在服務器端進行識別不同的用戶
    • Session的實現依賴于Cookie,如果Cookie被禁用,那么session也將失效

跨站攻擊

參考

  • CSRF(Cross-site request forgery, 跨站請求偽造)

CSRF顧名思義,是偽造請求,冒充用戶在站內的正常操作。我們知道,絕大多數網站是通過cookie等方式辨別用戶身份,再予以授權。所以要偽造用戶的正常操作,最后的辦法是通過XSS或鏈接欺騙等途徑,讓用戶在本機(即擁有身份cookie的瀏覽器端)發起用戶所不知道的請求

栗子:一論壇的發帖是通過GET請求訪問,點擊發帖之后JS把發帖內容拼接成目標URL并訪問http://example.com/bbs/create_post.php?title=標題&&content=內容那么,我只需要在論壇中發一貼,包含一鏈接http://example.com/bbs/create_post.php?title="我是腦殘"&&content="哈哈"只要用戶點擊了這個鏈接,那么他們的賬戶就會在不知情的情況下發布這一帖子。

**如何防范CSRF攻擊?**可以注意以下幾點:

  • 關鍵操作(如發帖等)只接受POST請求
  • 驗證碼:
    • CSRF攻擊的過程,往往是在用戶不知情的情況下構造網絡請求。所以如果使用驗證碼,那么每次操作都需要用戶進行互動,從而簡單有效的防御了CSRF攻擊
    • 但是如果你在一個網站中,做出任何舉動都要輸入驗證碼會嚴重影響用戶體驗,所以驗證碼一般只出現在特殊操作里面,或者在注冊時候使用
  • 檢查Refer
    • 常見的互聯網頁面與頁面之間是存在聯系的,比如你在www.baidu.com應該找不到通往www.google.com的鏈接的,再比如你再論壇留言,那么不管你留言后重定向到哪里去,之前的那個網址一定會包含留言的輸入框,這個之前的網址就會保留在新頁面頭文件的Referer中
    • 通過檢查Referer的值,我們就可以判斷這個請求是合法的還是非法的,但是問題出在服務器不是任何時候都能接受到Referer的值,所以Referer Check一般用于監控CSRF攻擊的放生,而不用來抵用攻擊
  • Token
    • 目前主流的做法是使用Token抵御CSRF攻擊：
      • CCSRF攻擊主要成功的條件在于攻擊者能夠預測所有的參數,從而構造出合法的請求.所以根據不可預測性原則,我們可以對參數進行加密從而防止CSRF攻擊
      • 另一個更通用的做法是保持原有參數不變,另外添加一個參數Token,其值是隨機的。這樣攻擊者因為不知道Token而無法構造出合法的請求進行攻擊
      • Token使用原則:
        • Token要足夠隨機 (這樣才無法預測)
        • Token是一次性的,即每次請求成功之后要更新Token(增加攻擊難度,預測難度)
        • Token要注意保密性(敏感操作使用POST,防止Token出現在URL中)

HTTPS

參考

HTTP請求都是明文(沒有經過加密的信息)傳輸,如果HTTP請求被黑客攔截,并且里面含有銀行卡密碼等敏感數據的話,會非常危險.為了解決這個問題,Netscape公司指定了HTTPS協議,HTTPS可以將數據加密傳輸,也就是傳輸的是密文,即便黑客在傳輸過程中攔截到數據也無法破譯,這就保證了網絡通信的安全.

密碼學基礎

明文: 未被加密過的原始數據

密文: 明文被某種加密算法加密之后,會變成密文,從而確保原始數據的安全。密碼也可以被解密得到原始的明文

密鑰: 密鑰是一種參數,它是在明文轉換為密文或密文轉換為明文的算法中輸入的參數。密鑰分為對稱密鑰與非對稱密鑰,分別應用在對稱加密和非對稱加密上

對稱加密: 對稱加密又叫做私鑰加密,即信息的發送方和接收方使用同一個密鑰去加密和解密數據。對稱加密的特點是算法公開、加密和解密速度快,適合于對大數據量進行加密,常見的對稱加密算法有: DES、3DES、TDEA、Blowfish、RC5和IDEA

其加密過程如下: 明文 + 加密算法 + 私鑰 => 密文

解密過程如下: 密文 + 解密算法 + 私鑰 => 明文

私鑰: 對稱加密中用到的密鑰叫做私鑰,私鑰表示個人私有的密鑰,即該密鑰不能被泄漏

由于對稱加密的算法是公開的,所以一旦私鑰被泄漏,那么密文就很容易被破解,所以對稱加密的確定是密鑰安全管理困難

非對稱加密: 使用一對密鑰公鑰和私鑰.私鑰被自己保存,不能對外泄漏.公鑰指的是公開的密鑰,任何人都可以獲得該密鑰。

被公鑰加密過的密文只能被私鑰解密,過程如下:

明文 + 加密算法 + 公鑰 => 密文 、密文 + 解密算法 + 私鑰 => 明文

被私鑰加密故的密文只能被公鑰解密,過程如下:

明文 + 加密算法 + 私鑰 => 密文、 密文 + 解密算法 + 公鑰 => 明文

HTTPS通信過程

HTTPS = HTTP + SSL/TLS,過程如下: 客戶端向服務器發送一條 HTTP 報文.先使用HTTP協議生成報文,然后通過SSL/TLS 對報文進行加密. 服務端得到報文后,先經過SSL/TLS對報文進行解密,然后再使用HTTP協議解析明文.具體步驟如下:

  1. 客戶端向服務器發起HTTPS請求,連接到服務器的443端口

  2. 服務器端有一個密鑰對,即公鑰和私鑰,公鑰公開出去.私鑰保存再服務器內部.

  3. 服務器將自己的公鑰發送給客戶端

  4. 客戶端收到服務端的公鑰后,會對公鑰進行檢查,驗證其合法性,如果發現公鑰有問題,那么HTTPS傳輸就無法繼續。如果公鑰合格,那么客戶端會生成一個隨機值,這個隨機值就是用于進行對稱加密的密鑰(稱之為 client key)

  5. 客戶端發起HTTPS中的第二次請求,使用服務器端的server public key對client key進行加密之后,將密文發送給服務端

  6. 服務端收到client key后,使用sever private key進行解密.得到client key的明文

  7. 之后客戶端和服務端都使用 client key 進行加解密.

根據上述所述: HTTPS的流程是先使用非對稱加密交換 對稱加密的密鑰. 之后使用對稱加密進行傳輸

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/news/250259.shtml
繁體地址，請注明出處：http://hk.pswp.cn/news/250259.shtml
英文地址，請注明出處：http://en.pswp.cn/news/250259.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

Spring AOP注解方式實現

Spring AOP注解方式實現

簡介 上文已經提到了Spring AOP的概念以及簡單的靜態代理、動態代理簡單示例&#xff0c;鏈接地址&#xff1a;https://www.cnblogs.com/chenzhaoren/p/9959596.html 本文將介紹Spring AOP的常用注解以及注解形式實現動態代理的簡單示例。 常用注解 aspect&#xff1a;定義切面…
閱讀更多...
享元模式-Flyweight(Java實現)

享元模式-Flyweight(Java實現)

享元模式-Flyweight 享元模式的主要目的是實現對象的共享,即共享池,當系統中對象多的時候可以減少內存的開銷,通常與工廠模式一起使用。 本文中的例子如下: 使用享元模式: 小明想看編程技術的書, 就到家里的書架上拿, 如果有就直接看, 沒有就去買一本, 回家看. 看完了就放到家里…
閱讀更多...
算法 --- 回溯法

算法 --- 回溯法

回溯法 參考 - 劍指Offer 回溯法可以看成蠻力法的升級版,它從解決問題每一步的所有可能選項里系統地選擇出一個可行的解決方案. 回溯法解決的問題的特性: 可以形象地用樹狀結構表示: 節點: 算法中的每一個步驟節點之間的連接線: 每個步驟中的選項,通過每一天連接線,可以到達…
閱讀更多...
013.Zabbix的Items(監控項)

013.Zabbix的Items(監控項)

一 Items簡介 Items是從主機里面獲取的所有數據&#xff0c;可以配置獲取監控數據的方式、取值的數據類型、獲取數值的間隔、歷史數據保存時間、趨勢數據保存時間、監控key的分組等。通常情況下item由key參數組成&#xff0c;如監控項中需要獲取cpu信息&#xff0c;則需要一個對…
閱讀更多...
Cookie 和 Session的區別

Cookie 和 Session的區別

pass 下次再寫轉載于:https://www.cnblogs.com/nieliangcai/p/9073520.html
閱讀更多...
算法 --- 記一道面試dp算法題

算法 --- 記一道面試dp算法題

題目: 給定一個數組(長度大于1),如下 let a [1,4,3,4,5] // 長度不確定,數值為整數要求寫一個函數,返回該數組中,除本身數字之外其他元素的成積.即返回如下: // 過程[4*3*4*5, 1*3*4*5, 1*4*4*5, 1*4*3*5, 1*4*3*4] // 結果[240, 60, 80, 60, 48]題目要求不使用除法,且時間…
閱讀更多...
編碼

編碼

一、什么是編碼&#xff1f;首先&#xff0c;我們從一段信息即消息說起&#xff0c;消息以人類可以理解、易懂的表示存在。我打算將這種表示稱為“明文”&#xff08;plain text&#xff09;。對于說英語的人&#xff0c;紙張上打印的或屏幕上顯示的英文單詞都算作明文。其次&a…
閱讀更多...
ASP.NET MVC 實現頁落網資源分享網站+充值管理+后臺管理（10）之素材管理

ASP.NET MVC 實現頁落網資源分享網站+充值管理+后臺管理（10）之素材管理

源碼下載地址&#xff1a;http://www.yealuo.com/Sccnn/Detail?KeyValuec891ffae-7441-4afb-9a75-c5fe000e3d1c 素材管理模塊也是我們這個項目的核心模塊&#xff0c;里面的增刪查改都跟文章管理模塊相同或者相似&#xff0c;唯一不同點可能是對附件的上傳處理&#xff0c;但…
閱讀更多...
javascript --- [express+ vue2.x + elementUI]登陸的流程梳理

javascript --- [express+ vue2.x + elementUI]登陸的流程梳理

說明 涉及到以下知識點: 登陸的具體流程express、vue2.x、elementUI、axios、jwt、assert 登陸方面的API使用中間件的使用前后端通過http狀態碼,進行響應的操作(這里主要是401)密碼驗證(bcrypt的hashSync方法對明文密碼進行加密,compareSync方法對加密的密碼進行驗證)token的…
閱讀更多...
設計模式---裝飾模式

設計模式---裝飾模式

今天學習了裝飾模式&#xff0c;做個筆記。。裝飾模式的基礎概念可以參考&#xff1a;https://blog.csdn.net/cjjky/article/details/7478788 這里&#xff0c;就舉個簡單例子 孫悟空有72變&#xff0c;但是它平時是猴子&#xff0c;遇到情況下&#xff0c;它可以變成蝴蝶等等 …
閱讀更多...
springMvc 注解@JsonFormat 日期格式化

springMvc 注解@JsonFormat 日期格式化

1&#xff1a;一定要加入依賴,否則不生效&#xff1a; <!--日期格式化依賴--><dependency><groupId>com.fasterxml.jackson.core</groupId><artifactId>jackson-databind</artifactId><version>${jackson.version}</version>&…
閱讀更多...
Git很簡單--圖解攻略

Git很簡單--圖解攻略

Git Git 是目前世界上最先進的分布式版本控制系統&#xff08;沒有之一&#xff09;作用 源代碼管理為什么要進行源代碼管理? 方便多人協同開發方便版本控制Git管理源代碼特點 1.Git是分布式管理.服務器和客戶端都有版本控制能力,都能進行代碼的提交、合并、. 2.Git會在根…
閱讀更多...
css --- 使用scss生成常用的基本css樣式

css --- 使用scss生成常用的基本css樣式

"工具樣式"的概念和 SASS(SCSS) 在webpack中使用sass 安裝sass和sass-loader $ npm i sass sass-loader由于使用了腳手架,安裝完畢后重啟前端即可 樣式重置 其實就是樣式的初始化 // reset* {box-sizing: border-box; // 以邊框為準. css3盒模型outline: none;…
閱讀更多...
vc/vs開發的應用程序添加dump崩潰日志轉

vc/vs開發的應用程序添加dump崩潰日志轉

原貼地址&#xff1a;https://blog.csdn.net/wangkui1331/article/details/78029940 vc/vs開發的應用程序出現崩潰的時候&#xff0c;由于沒有任何記錄&#xff0c;導致開發人員很難追蹤&#xff0c;但是添加dump文件后&#xff0c;就可以免除這些煩惱 1.添加方法 &#xff08;…
閱讀更多...
51 nod 1127最短的包含字符串（尺取法)

51 nod 1127最短的包含字符串（尺取法)

1127 最短的包含字符串 收藏關注給出一個字符串&#xff0c;求該字符串的一個子串S&#xff0c;S包含A-Z中的全部字母&#xff0c;并且S是所有符合條件的子串中最短的&#xff0c;輸出S的長度。如果給出的字符串中并不包括A-Z中的全部字母&#xff0c;則輸出No Solution。Input…
閱讀更多...
Java --- 基礎學習Ⅰ

Java --- 基礎學習Ⅰ

第一章 開發前言 位、字節 位(bit): 一個數字0或一個數字1,代表一位 字節(Byte): 每逢8位是一個字節,這時數據存儲的最小單位 1 Byte 8 bit 1 KB 1024 Byte 1 MB 1024 KB 1 GB 1024 MB 1 TB 1024 GB 1 PB 1024 TB MS-DOS(Microsoft Disk Operating System) 第二章 Ja…
閱讀更多...
JSON 數據重復 出現$ref

JSON 數據重復 出現$ref

JSONArray 類型 如果我們往里面add數據的時候 如果數據相同&#xff0c;那么就會被替換成 $ref: 也就是被簡化了 因為數據一樣所直接 指向上一條數據 循環引用&#xff1a;當一個對象包含另一個對象時&#xff0c;fastjson就會把該對象解析成引用。引用是通過$ref標示的&am…
閱讀更多...
Java --- 基礎學習Ⅱ

Java --- 基礎學習Ⅱ

繼承 繼承概述 下面有一個學生類 public class Student{private String name;private int age;public void study(){System.out.println("努力學習了");}public String getName() {return name;}public void setName(String name) {this.name name;}public int g…
閱讀更多...
urllib庫

urllib庫

python內置的最基本的HTTP請求庫&#xff0c;有以下四個模塊&#xff1a; urllib.request　　請求模塊 urllib.error　　　 異常處理模塊 urllib.parse　　　url解析模塊 urllib.robotparser robots.txt解析模塊 urllib.request請求模塊&#xff1a; urllib.request.urlopen(u…
閱讀更多...
layer的刪除詢問框的使用

layer的刪除詢問框的使用

刪除是個很需要謹慎的操作 我們需要進行確認 對了刪除一般使用ajax操作 因為如果同url請求 處理 再返回 會有空白頁 1.js自帶的樣式 <button type"button" data-toggle"tooltip" title"刪除" class"btn btn-danger pull-right btn-xs&qu…
閱讀更多...
最新文章

Copyright @ 2022~2023