อยากสร้างเว็บที่รับโหลดได้เยอะ มีประสิทธิภาพสูง และจัดการกับ Request ได้แบบไหลลื่น ทำยังไงได้บ้าง ?
.
ต้องเจ้านี่ Nginx ซอฟต์แวร์ที่ช่วยจัดการ Request ต่าง ๆ ได้อย่างมีประสิทธิภาพ !! และวันนี้แอดจะพาเพื่อน ๆ มาทำความรู้จักกับเจ้านี่กันแบบคร่าว ๆ ว่ามันคืออะไร ทำงานยังไง หากพร้อมกันแล้ว ไปติดตามกันได้เลย 👇 😊
.
.
💡 รู้จัก Nginx
Nginx หรืออ่านว่า Engine-X เป็นเว็บเซิร์ฟเวอร์ที่สามารถรองรับผู้ใช้งานได้หลากหลาย และมีประสิทธิภาพสูง เป็น Open-Source รองรับ Reverse Proxying, Caching, Load Balancing สำหรับเซิร์ฟเวอร์ HTTP, TCP และ UDP, และการทำ Media Streaming นอกจากนี้ยังสามารถใช้เป็น Proxy Server สำหรับอีเมล์ (IMAP, POP3, and SMTP) ได้อีกด้วย
.
โดยส่วนใหญ่แล้วจะถูกใช้งานกับเว็บที่มีการอัพโหลด หรือ ดาวน์โหลดบ่อย ๆ หรือใช้ในการ Streaming สามารถรองรับการเชื่อมต่อในปริมาณมาก จัดการ Traffic ได้อย่างมีประสิทธิภาพและรวดเร็ว
.
.
⚙️ Nginx ทำงานยังไง ?
Nginx สร้างขึ้นเพื่อจัดการกับ Request ต่าง ๆ แบบ Asynchronous รับ Request พร้อมกันได้โดยไม่บล็อก Request อื่น ๆ โดยไม่เปลืองหน่วยความจำ กินทรัพยากรน้อย ทำให้ CPU และ RAM ทำงานได้มากยิ่งขึ้นนั่นเอง
.
ซึ่ง Nginx จะมีฟีเจอร์เด่น ๆ ดังนี้
🔹 Reverse proxy with caching
🔹 IPv6
🔹 Load balancing
🔹 FastCGI support with caching
🔹 WebSockets
🔹 Handling of static files, index files, and auto-indexing
🔹 TLS/SSL with SNI
.
NGINX จะถูกวางไว้ระหว่าง Clients และ Web Server เพื่อจัดการ SSL/TLS หรือใช้เพื่อเร่งความเร็วของเว็บ เป็นตัวกลางในการจัดการงานที่อาจจะทำให้เว็บเซิร์ฟเวอร์ของเราช้าลง เช่น Negotiating SSL/TLS, การบีบอัดและแคชเนื้อหาเพื่อปรับปรุงประสิทธิภาพ ซึ่งสามารถใช้กับเว็บที่สร้างขึ้นจากอะไรก็ได้ ไม่ว่าจะเป็น Node.js หรือ PHP ซึ่งส่วนใหญ่แล้วจะแคชเนื้อหาและ Reverse Proxy เพื่อลดภาระงานบนเซิร์ฟเวอร์ ใช้สามารถใช้ประโยชน์จากฮาร์ดแวร์ได้อย่างเต็มที่
.
.
✨ ข้อดี
🔸 มีความปลอดภัย รองรับมาตรฐาน HTTP/2
🔸 รองรับการทำงานของ HTTP
🔸 ประมวลผลได้รวดเร็ว
🔸 ทำงานแบบ Asynchronous รองรับ Request เยอะ ๆ ได้เป็นอย่างดี
.
.
⚠️ ข้อจำกัด
🔹 การ config ค่อนข้างซับซ้อน
🔹 ดูแลจัดการได้ยาก และไม่ค่อยมีความยืดหยุ่น
.
.
📑 อ่านข้อมูลเพิ่มเติมได้ที่นี่ : https://kinsta.com/knowledgebase/what-is-nginx/ , https://www.nginx.com/resources/glossary/nginx/
.
borntoDev - 🦖 สร้างการเรียนรู้ที่ดีสำหรับสายไอทีในทุกวัน
#Nginx #BorntoDev
「udp proxy」的推薦目錄:
- 關於udp proxy 在 BorntoDev Facebook 的最讚貼文
- 關於udp proxy 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
- 關於udp proxy 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於udp proxy 在 simple udp proxy solution - Stack Overflow 的評價
- 關於udp proxy 在 MengRao/TCP-UDP-Proxy - GitHub 的評價
- 關於udp proxy 在 The Top 21 Udp Proxy Open Source Projects on Github 的評價
- 關於udp proxy 在 Exposing TCP and UDP services - NGINX Ingress Controller 的評價
- 關於udp proxy 在 Envoy Proxy: UDP Support - YouTube 的評價
- 關於udp proxy 在 Low-level tcp/udp proxy - Unix & Linux Stack Exchange 的評價
- 關於udp proxy 在 ADRFranklin/samp-udp-proxy - githubmemory 的評價
- 關於udp proxy 在 udp-proxy · GitHub Topics 的評價
udp proxy 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
最近跟大家分享一個 2020 年初左右的問題,這個問題的徵狀使用者透過 service 去存取相關服務時,會一直遲遲連接不上,直到 63 秒後服務才會通。
這個問題有兩種類型,一個是 63 秒後服務會通,一個則是 1 秒後會通,兩個背後的原因都一樣,這邊就來稍微簡介一下這個問題
# 發生條件
1. 使用 VXLAN 作為底層 Overlay Network,最常見的就是 Flannel 這套 CNI
2. Kubernetes 的版本不能太舊,至少要 1.16 以後,不過目前這個問題已經修復,所以現在要撞到除非特別指定版本
3. 使用的 Linux Kernel 版本也不能太新,目前該問題已經修復於大部分的 upstream
# 發生原因
1. VXLAN 本身是一個基於 UDP 的封裝協議,有一個已知的 bug 會使得其 checksum 發生錯誤,導致封包不會被遠端接收方給接收
2. kube-proxy 內關於 iptables 的設定沒有妥善,導致 VXLAN 封包會進行二次 SNAT
3. 第二次的 SNAT 就會觸發(1) 的 bug(當然還有其他條件,但是那些條件也剛好符合)
,最後導致封包的 checksum 不同,因此送到遠方就被拒絕
4. 底層的 TCP 建立連線時,會不停地嘗試,每次失敗都會等待更多時間,分別是1,2,4,8,16,32秒
5. 五次都失敗後, TCP 就會觸發重傳機制,下一次的重傳就不會進入到第二次的 SNAT,因此封包就不會踩到問題,因此通過
# 解決方法
1. 基本上這個問題要踩到要各方一起努力才會踩到,也因此修復方式也是多元化
2. Kernel 本身修復了關於 UDP 封裝的 Checksum 計算
3. Kubernetes 這邊則是針對 kube-proxy 進行強化,其使用的 iptables 規則會避免二次 SNAT 的情況
# 其他問題
1. 為什麼 TCP 重送後就不會踩到二次 SNAT? 這部分我看了相關的 issue 以及諸多文章都沒有看到解釋,都在探討 SNAT 後產生的 checksum,至於為什麼 TCP 重送後就通則是一個謎底
2. 為了解決這個謎體,我特別指定 kubernetes 版本並且重新編譯 Ubuntu 的 Linux Kernel 版本,盼望從 Kernel 中來觀察並且理解這個問題,目前已經有一些初步的進度。之後完成後會在撰寫文章跟大家分享這個問題
這個問題我認為非常有趣,也許自己的環境剛好沒有踩到,但是可以透過觀察不同的 issue 來研究各式各樣問題,也藉由這些過程來學習
相關 PR: https://github.com/kubernetes/kubernetes/pull/92035
udp proxy 在 矽谷牛的耕田筆記 Facebook 的最佳解答
今天這篇文章來分享一下對於昨天所談的 UDP Race Condition 的解法,主要是針對 Kubernetes dns 問題去探討,
一個作法就是透過 nodelocaldns 這種不同的架構,該架構下會於每個節點上部屬一個 DNS Cache,所有該節點上的 Pod 都會透過 UDP 與該 DNS Cache 溝通。 而這段網路請求因為發生於同節點上,所以 kube-proxy 產生的規則不會介入,因此那些 iptables/ipvs/conntrack 就不會影響到,就不會產生上次所說的 bug.
接者,每個節點上的 DNS cache 會透過 TCP 的方式去跟 kube-dns 來詢問最後的答案,透過 TCP 重送的方式來減緩封包遺失造成的 timeout 問題
https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/
https://github.com/kubernetes/kubernetes/issues/56903
udp proxy 在 MengRao/TCP-UDP-Proxy - GitHub 的推薦與評價
A proxy server program written in C++ that can forward TCP or UDP packets to and from some pre-configured address. It's a transparent proxy in that remote ... ... <看更多>
udp proxy 在 The Top 21 Udp Proxy Open Source Projects on Github 的推薦與評價
Browse The Most Popular 21 Udp Proxy Open Source Projects. ... SOCKS5 proxies,WEBSOCKET, TCP, UDP proxy server implemented by golang. ... <看更多>
udp proxy 在 simple udp proxy solution - Stack Overflow 的推薦與評價
... <看更多>
相關內容