Hệ điều hành – Fullstack Station https://fullstackstation.com Hướng dẫn lập trình, thiết kế, lập trình web, thiết kế web, lập trình javascript, lập trình fullstack từ cơ bản đến nâng cao Mon, 22 Apr 2024 11:08:02 +0000 vi hourly 1 https://wordpress.org/?v=6.4.5 https://fullstackstation.com/wp-content/uploads/2019/08/favicon.ico Hệ điều hành – Fullstack Station https://fullstackstation.com 32 32 Một số lệnh hữu ích cho xử lý tập tin, thư mục bằng command line https://fullstackstation.com/mot-so-lenh-huu-ich-cho-xu-ly-tap-tin-thu-muc-bang-command-line/ https://fullstackstation.com/mot-so-lenh-huu-ich-cho-xu-ly-tap-tin-thu-muc-bang-command-line/#respond Wed, 13 Mar 2019 08:52:32 +0000 http://fullstackstation.com/?p=1473 Mấy hôm nay dính vài vấn đề với hệ thống nên phải tra log và xử lý text, nhân tiện ghi chép lại mấy cái lệnh hữu ích chia sẽ với mọi người. Grep Thường thì “grep” được dùng để tìm kiếm text trong file, rất hay được dùng khi kiểm tra log hoặc tập […]

The post Một số lệnh hữu ích cho xử lý tập tin, thư mục bằng command line appeared first on Fullstack Station.

]]>
Mấy hôm nay dính vài vấn đề với hệ thống nên phải tra log và xử lý text, nhân tiện ghi chép lại mấy cái lệnh hữu ích chia sẽ với mọi người.

Grep

Thường thì “grep” được dùng để tìm kiếm text trong file, rất hay được dùng khi kiểm tra log hoặc tập tin văn bản.

$ grep 'keyword' /var/log/path.log

Một số tuỳ chọn hữu ích

$ grep -A 5 -B 6 --color 'keyword' /var/log/path.log

Lệnh trên sẽ làm nổi bật `keyword` bằng màu sắc với --color, và -A 5hiển thị 5 dòng sau (A: After) dòng có chứa keyword, tương tự với -B 6 là hiển thị 6 dòng trước (B: Before) dòng có chứa keyword, nếu dùng -C 7 thì nghĩa là trước 7 dòng và sau 7 dòng.

Kết hợp wc

Chúng ta sẽ kết hợp với wc (wordcount) để đếm số dòng, số byte, số ký tự mà chúng ta cần

$ grep 'keyword' /var/log/path.log | wc -l

Với lệnh trên, thì sẽ đếm xem có bao nhiêu dòng chứa `keyword`, hoặc thay thế tuỳ chọn -l bằng -m sẽ đếm xem có bao nhiêu ký tự, hoặc -c sẽ đếm byte, thường dùng nhất vẫn chỉ có -l.

Kết hợp awk

$ cat access.log | awk '{print $1}'

Nâng cao thêm 1 chút bằng printf

$ cat access.log | awk '{printf ("Nội dung là %s %s", $1, $2)}'

Ứng dụng vào việc tìm IP có số lượng gởi yêu cầu vào máy chủ nhiều nhất

$ cat access.log | awk '{print $1}' | sort -n | uniq -c | sort -nr | head -20

Giả sử $1 ở đây là IP (file log thông thường của server), thì lệnh awk sẽ lấy danh sách IP, và được sắp xếp và lấy duy nhất không trùng lặp bằng lệnh sort -n | uniq -c sau đó sắp xếp đảo ngược với sort -nr và kết thúc là lấy 20 kết quả đầu tiên bằng head -20

Tìm kiếm tập tin, thư mục bằng Find

Lệnh find cũng ít khi sử dụng, nhưng tầm quan trọng và tính hữu dụng thì rất cao.

find -type f -name ‘*.log’ -mtime +15

Câu lệnh trên cơ bản tìm trong thư mục hiện hành tất cả các tập tin có đuôi .log với thời gian cập nhật mtime hơn 15 ngày (+15) hoặc có thể tìm theo thời gian tạo bằng ctime

Lệnh này được sử dụng khi cần xoá các tập tin khi dung lượng ổ cứng bị đầy, hoặc là cần lập lịch tự động xoá file backup sau 15 ngày chẳng hạn.

Kết hợp xoá tập tin

find -type f -name ‘*.log’ -mtime +15 -exec rm {} \;

hoặc

find -type f -name ‘*.log’ -mtime +15 | xargs rm

Tìm thư mục có dung lượng cao

du -h | sort -hr | head -5

Câu lệnh trên cho phép tìm 5 thư mục có dung lượng cao nhất trong thư mục hiện hành, nếu ta thêm --max-depth=1 thì lệnh chỉ giới hạn ở thư mục con cấp 1.

Fullstack Station Tips

Có hằng hà sa số câu lệnh cần thiết, nhưng mấy lệnh này mình hay sử dụng nhất. Từ các lệnh cơ bản này, bạn có thể xem phần `help` của mỗi lệnh để có thêm tuỳ chọn.

The post Một số lệnh hữu ích cho xử lý tập tin, thư mục bằng command line appeared first on Fullstack Station.

]]>
https://fullstackstation.com/mot-so-lenh-huu-ich-cho-xu-ly-tap-tin-thu-muc-bang-command-line/feed/ 0
Serverless là gì? Hãy sẵn sàng với serverless! https://fullstackstation.com/serverless-la-gi/ https://fullstackstation.com/serverless-la-gi/#comments Wed, 28 Nov 2018 06:45:15 +0000 http://fullstackstation.com/?p=1431 Khái niệm về serverless là gì thì cũng không còn mới mẻ lắm cho nhiều người, tuy nhiên để thực sự sử dụng, trải nghiệm ưu khuyết điểm thực tế thì cũng không phải nhiều lắm. Sau một thời gian nghiên cứu về serverless, mình tổng kết một vài kinh nghiệm cá nhân, cố gắng […]

The post Serverless là gì? Hãy sẵn sàng với serverless! appeared first on Fullstack Station.

]]>
Khái niệm về serverless là gì thì cũng không còn mới mẻ lắm cho nhiều người, tuy nhiên để thực sự sử dụng, trải nghiệm ưu khuyết điểm thực tế thì cũng không phải nhiều lắm. Sau một thời gian nghiên cứu về serverless, mình tổng kết một vài kinh nghiệm cá nhân, cố gắng giải thích đơn giản để người mới dễ dàng tiếp cận lĩnh vực này.

Cập nhật 04/2024: Serverless AI là gì?

Serverless là gì?

Serverless là môi trường, nền tảng thực thi ứng dụng và dịch vụ mà không phải quan tâm đến máy chủ. Ứng dụng serverless không cần phải  quan tâm việc phân bổ, quản lý tài nguyên của hệ điều hành, và bỏ qua các vấn đề về nâng cấp và bảo mật. Với khái niệm là chỉ cần tập trung phát triển sản phẩm, việc còn lại về vận hành sẽ để nền tảng này đảm nhiệm.

Điều quan trọng và khác biệt nhất trong serverless là bạn chỉ trả tiền khi và chỉ những phần bạn sử dụng. Giả sử bạn có một máy chủ ảo, thì thường sẽ được tính tiền trọn gói bao gồm thời gian chạy 24/7 trong 1 tháng, CPU và RAM, băng thông, lưu trữ. Bạn vẫn sẽ phải trả tiền hàng tháng đều đặn cho dù cái máy chủ ảo đó không chạy, hoặc chỉ sử dụng 5~10% công suất thì bạn vẫn phải trả trọn gói. Hiểu một cách nôm na, thì serverless như gói cước điện thoại được tính theo block giây, gọi bao nhiêu tính tiền bấy nhiêu, còn máy chủ ảo thường thì phải trả tiền thuê bao hàng tháng dù có phải sử dụng hay không.

Ưu và nhược điểm của serverless

Ưu điểm

Xây dụng ứng dụng serverless đồng nghĩa với việc bạn chỉ tập trung vào sản phẩm cốt lõi thay vì phải lo lắng về việc quản lý và vận hành nhiều máy chủ hoặc thời gian chạy, dù trên nền tảng đám mây hay tự xây dựng hệ thống máy chủ. Sự cắt giảm công sức tổng thể này sẽ giúp cho các nhà phát triển dành thời gian và năng lượng để tập trung vào việc xây dựng các sản phẩm tuyệt vời có quy mô linh hoạt và ổn định cao.

Không cần quản lý máy chủ: Bạn sẽ không cần cung cấp hay duy trì bất kỳ máy chủ nào. Sẽ không cần phần mềm hoặc thời gian chạy để cài đặt, nâng cấp hoặc quản trị.

Thay đổi quy mô một cách linh hoạt: Ứng dụng của bạn sẽ có khả năng thay đổi quy mô tự động hoặc bằng cách điều chỉnh dung lượng thông qua việc chuyển đổi đơn vị sử dụng (ví dụ: thông lượng, bộ nhớ) thay vì với máy chủ độc lập thì sẽ phức tạp hơn.

Độ sẵn sàng cao: Ứng dụng serverless có độ sẵn sàng tích hợp và dung sai cao. Bạn sẽ không cần tạo kiến trúc cho các khả năng này do các dịch vụ chạy ứng dụng đã cung cấp cho ứng dụng theo mặc định. Ngoài ra, có để chọn trung tâm dữ liệu (một hoặc nhiều nơi) để triển khai sản phẩm một cách dễ dàng.

Tiết kiệm chi phí: chi phí gần như bằng 0 sau khi triển khai nếu bạn không có request nào (hoặc không có hành động gọi hàm), còn sử dụng bao nhiêu thì tính tiền bấy nhiêu.

Khuyết điểm

Serverless là một ý tưởng tuyệt vời nhưng không hoàn hảo, serverless có những vấn đề riêng mà bạn cũng phải suy nghĩ trước khi quyết định sử dụng:

Độ trễ: Hiệu suất có thể là một vấn đề, chính bản thân mô hình này có thể gây ra độ trễ lớn hơn trong quá trình các nguồn tài nguyên điện toán phản ứng lại với lệnh của các ứng dụng. Nếu khách hàng yêu cầu hiệu suất cao thì việc sử dụng các máy chủ ảo được phân bổ sẽ là một lựa chọn ưu việt hơn.

Gỡ lỗi (Debug): Công việc giám sát và gỡ lỗi của serverless computing cũng khá khó khăn. Việc bạn không sử dụng một nguồn tài nguyên máy chủ thống nhất làm cho cả hai hoạt động này gặp nhiều trở ngại. (Tin tốt là công cụ này sẽ dần được để cải thiện xử lý giám sát và gỡ lỗi tốt hơn trong môi trường không máy chủ.). Ngoài ra, để giám sát thường cần có 1 thêm các công cụ tương ứng nền tảng đó, chi phí có thể phát sinh thêm.

Giới hạn về bộ nhớ, thời gian: các nhà cung cấp đều giới hạn tài nguyên ở các mức cố định về bộ nhớ và thời gian thực thi (timeout). Giả sử timeout tối đa là 5 phút, nếu bạn chạy quá 5 phút, quá trình thực thi sẽ bị ngắt. Về bộ nhớ, thì sẽ thiết lập mỗi mức khác nhau tuỳ nhà cung cấp, AWS có memory là 3008MB (sẽ được cấp CPU cao tương ứng), nếu ứng dụng yêu cầu bộ nhớ lớn thì sẽ không đáp ứng được. Liên quan đến vấn đề bộ nhớ này, thì cũng cần phải lưu tâm lúc lập trình nên tối ưu tốt, để tiết kiệm chi phí.

Phụ thuộc nhà cung cấp: bạn không thể muốn chạy phiên bản của phần mềm, nền tảng chính xác như bạn muốn. Ví dụ Nodejs bạn cần 10.x nhưng nhà cung cấp chỉ hỗ trợ đến 8.x, thì bạn sẽ không sử dụng được nền tảng này. Như vậy, trước khi sử dụng, bạn cần cân nhắc các nền tảng được hỗ trợ.

Chi phí ngầm: tuỳ nhà cung cấp có tính hay không, nhưng cơ bản là sẽ phát sinh chi phí lưu trữ mã nguồn, băng thông, và chi phí về lưu trữ dữ liệu (tuỳ ứng dụng có sử dụng hay không, ví dụ DynamoDB, RDMS … thì sẽ được tính riêng). Mặc dù, tuy không nhiều nhưng nếu không tối ưu, các phần chi phí ngầm sẽ còn cao hơn cả chi phí cho serverless.

Thời gian để nghiên cứu: trước đây bạn phải học cách sử dụng, quản lý máy chủ thì giờ đây bạn cũng cần thời gian để học để quản lý các tài nguyên trong serverless, mặc dù ko phải quá khó như quản lý máy chủ, nhưng không thể không tính. Ví dụ bạn sẽ mất thời gian để hiểu về cách sử dụng CloudFormation, IAM policies, quản lý cấu hình về stage, region, memory của Functions…

Khi nào nên sử dụng serverless

Có rất nhiều trường hợp có thể ứng dụng được serverless, điểm chung là tất cả những ứng dụng không dính dáng đến điểm yếu của serverless 😀

Websites và APIs: hoàn toàn có thể xây dựng 1 website hoặc API, website có thể là động hoặc là bán tĩnh (bán tĩnh nghĩa là nguồn gốc file là tĩnh, nhưng dùng route động). Thường thì người ta hay xây dựng Restful API với serverless, nhưng mình thích áp dụng cho Graphql hơn, vì Restful có thể trả về dữ liệu không dùng tới nhưng mình phải trả tiền băng thông 😀 (Xem thêm Graphql là gì).

Xử lý đa phương tiện: các thao tác xử lý hình ảnh, video với yêu cầu không quá cao như cắt, nén, định dạng kích thước ảnh, tạo ảnh thumbnail, hoặc chuyển đổi bộ mã của video để phù hợp với thiết bị tương ứng.

Xử lý sự kiện: có thể đóng vai trò như 1 công tắc cầu giao để thực hiện một loạt các hành động khác khi được kích hoạt tuỳ theo sự kiện.

Xử lý dữ liệu: tuỳ theo ngữ cảnh mà có thể ứng dụng như chatbot, IoT,… lý do mà serverless thích hợp với mảng này vì với chatbot hay IoT chúng ta không biết khi nào dữ liệu sẽ tới, khi nào sẽ cần xử lý dữ liệu nên chúng ta không cần phải xây dựng máy chủ luôn luôn chạy và lãng phí ở thời gian chờ.

So sánh một số nhà cung cấp hàng đầu

Hiện nay có rất nhiều nhà cung cấp dịch vụ giúp bạn tạo ra các functions sử dụng mô hình serverless một cách khá dễ dàng:

  • AWS Lambda: nói về thị phần cung cấp hạ tầng cloud hiện nay thì AWS vấn đang dẫn đầu và họ cũng đưa ra dịch Lambda để người dùng có thể sử dụng và tạo ra các functions trên mô hình serverless. Khi kết hợp với các dịch vụ khác như API Gateway, S3,.. thì có thể tạo được một API server hay một hệ thống tự động xử lí khi có file upload lên S3. AWS Lambda hỗ trợ khá nhiều ngôn ngữ như Node.js, Java, C#, Python,…
  • Google Cloud Function: hỗ trợ ngôn ngữ khá đa dạng (Nodejs, Go, Python, Java, PHP, .NET Core)
  • Azure Functions: hàng của Microsoft, hỗ trợ C#, JavaScript, F#, Python, Batch, PHP, PowerShell

Còn nhiều nhà cung cấp khác như Kubeless, Fn,… tuy nhiên 3 ông ở trên có lẽ có thị phần lớn nhất và được quan tâm hơn. Ở dưới là chi tiết so sánh 1 số thông số giữa AWS Lambda, Google Cloud Function và Azure Function

Tính năngAWS LambdaGoogle CloudAzure Functions
Khả năng mở rộngTự độngTự độngBằng tay hoặc theo plan đặt trước
Số Function tối đaKhông giới hạn1000 trên 1 projectKhông giới hạn
Xử lí đồng thời1000 trên 1 account 1 region (soft limit)Không giới hạnKhông giới hạn
Thời gian xử lí tối đa300 sec (5 min)540 seconds (9 minutes)300 sec (5 min)
Ngôn ngữJavaScript, Java, C#, and PythonNodejs, Go, Python, Java, PHP, .NET CoreC#, JavaScript, F#, Python, Batch, PHP, PowerShell
Cài đặt dependenciesĐóng gói trong source packpageNpm, NuGet
DeploymentsChỉ dùng ZIP upload (to Lambda or S3)ZIP upload, Cloud Storage hoặc Cloud Source RepositoriesVisual Studio Team Services, OneDrive, Local Git repository, GitHub, Bitbucket, Dropbox, External repository
Biến môi trườngApp Settings và ConnectionStrings trong App Services
VersioningVersions và aliasesCloud Source branch/tagCloud Source branch/tag
Event-drivenS3, SNS, SES, DynamoDB, Kinesis, CloudWatch, Cognito, API Gateway, CodeCommit, etc.Cloud Pub/Sub hoặc Cloud Storage Object Change NotificationsBlob, EventHub, Generic WebHook, GitHub WebHook, Queue, Http, ServiceBus Queue, Service Bus Topic, Timer triggers
Hỗ trợ HTTP(S)API GatewayHTTP triggerHTTP trigger
OrchestrationAWS Step FunctionsChưa hõ trợAzure Logic Apps
LoggingCloudWatch LogsStackdriver LoggingApp Services monitoring
MonitoringCloudWatch & X-RayStackdriver MonitoringApplication Insights
In-browser code editorChỉ cho Cloud Source RepositoriesFunctions environment, App Service editor
Granular IAMIAM rolesChưa hỗ trợIAM roles
Pricingfree 1M requests, sau đó $0.20/1M requests, thêm $0.00001667/GB-secfree 1M requests, sau đó $0.40/1M requests, thêm $0.00000231/GB-secfree 1M requests, sau đó $0.20/1M requests, thêm $0.000016/GB-s

Xây dựng hệ thống để trở thành nhà cung cấp serverless

Vì sự nổi trội về ưu điểm của serverless, nên hiện nay cũng đã có một số mã nguồn mở để xây dựng thành nền tảng cung cấp serverless

https://www.serverless.com/

OpenFaaS – Serverless Functions Made Simple

https://github.com/openfaas/faas

FireCracker – Secure and fast microVMs for serverless computing

https://github.com/firecracker-microvm/firecracker

Mình thì chỉ quan tâm tới việc xài thôi, nên không tìm hiểu được ở mảng này.

Fullstack Station Tips

Ngày nay khi mà các công cụ hỗ trợ lập trình viên tập trung vào việc xây dựng sản phẩm càng nhiều, thì rõ ràng chính lập trình viên chính là những người hưởng lợi nhất. Serverless là tương lai của những lập trình viên độc lập, khi không còn phụ thuộc vào phần cứng, máy chủ nữa.

Serverless giúp cho chúng ta không còn lo về chi phí duy trì máy chủ, không còn lo khi sản phẩm chưa có doanh thu đã phải trả tiền duy trì. Cho dù serverless là không hoàn hảo, nhưng với những ưu điểm nhiều hơn khuyết điểm và khả năng ứng dụng rộng lớn, serverless là một mảnh đất màu mỡ cho bạn phát triển.

Bạn không cần phải cân nhắc nhiều giữa các nền tảng, hãy chọn nền tảng nào bạn đã có kiến thức, hoặc được khuyến mại – giảm chi phí sử dụng. Các nhà hạ tầng luôn luôn phát triển, nên ngoại trừ về đặc điểm ngôn ngữ, các nhà cung cấp đều tương đương nhau. Hãy tập trung vào sản phẩm của mình là tốt rồi, khi có rào cản – tức là đã đạt giới hạn của sản phẩm – cũng có nghĩa là đã có thể có doanh thu, lợi nhuận thì lúc này mới nên tìm hiểu thêm để chuyển qua hệ thống cung cấp serverless khác là ổn nhất.

Quan điểm của Fullstack Station là đa năng, gọn nhẹ và không phụ thuộc, muốn trở thành lập trình viên độc lập thì càng nên học và ứng dụng serverless.

Tham khảo:

http://tech.vtijapan.co.jp/serverless-gioi-thieu-chung-chung/

https://serverless.com/learn/use-cases/

https://www.alibabacloud.com/blog/4-use-cases-of-serverless-architecture_593862

https://epsagon.com/the-best-5-use-cases-for-the-serverless-beginner/

The post Serverless là gì? Hãy sẵn sàng với serverless! appeared first on Fullstack Station.

]]>
https://fullstackstation.com/serverless-la-gi/feed/ 2
Centos hay Ubuntu dành cho khởi nghiệp https://fullstackstation.com/centos-hay-ubuntu-danh-cho-khoi-nghiep/ https://fullstackstation.com/centos-hay-ubuntu-danh-cho-khoi-nghiep/#respond Wed, 23 Mar 2016 02:01:28 +0000 https://www.businesscard.vn/blog/?p=295 Về khởi nghiệp/startup Chắc hẳn bạn cũng như mình khi rất đau đầu trong việc chọn hệ thống máy chủ nào để sử dụng. Việc chọn lựa hệ thống máy chủ nào thường phải phụ thuộc vào kiến thức của người sử dụng và môi trường phù hợp để cài các ứng dụng, phần mềm […]

The post Centos hay Ubuntu dành cho khởi nghiệp appeared first on Fullstack Station.

]]>
Về khởi nghiệp/startup

Chắc hẳn bạn cũng như mình khi rất đau đầu trong việc chọn hệ thống máy chủ nào để sử dụng. Việc chọn lựa hệ thống máy chủ nào thường phải phụ thuộc vào kiến thức của người sử dụng và môi trường phù hợp để cài các ứng dụng, phần mềm hỗ trợ liên quan. Do chủ đề này khá rộng, và cũng không có khái niệm tốt nhất nên mình chỉ viết dựa trên các tiêu chí sau phù hợp với khởi nghiệp công nghệ fullstack:

  • Hỗ trợ của cộng đồng
  • Tài liệu
  • Cần thích ứng, thay đổi nhanh
    Về vấn đề thích ứng, thay đổi nhanh là tiêu chí quan trọng cho khởi nghiệp do công nghệ hiện tại phát triển rất nhanh, sản phẩm thường sử dụng các công nghệ mới

So sánh Centos và Ubuntu

Hệ thống quản lý gói phần mềm

yum và apt: cả 2 hệ thống gói phần mềm này đáp ứng hầu hết mọi trường hợp, nhu cầu phần mềm. Có vấn đề chẳng qua bạn quan tâm đến các gói mới, thì đây là lúc phát huy thế mạnh của Ubuntu, với tần suất cập nhật nhiều hơn so với Centos. Làm khởi nghiệp cần nhanh, đa phần sản phẩm của bạn sẽ chết trước khi bản cập nhật tiếp theo của hệ điều hành, vậy tại sao phải quan tâm đến tính “stable” của hệ điều hành, của các gói phần mềm một cách quá mức?

Cộng đồng hỗ trợ

Google Search:
ubuntu community: 40 triệu kết quả
centos community: 2 triệu kết quả
centos book: 1 triệu kết quả
ubuntu book: 16 triệu kết quả
sách về ubuntu: 194.000 kết quả
sách về centos: 97.000 kết quả
learn ubuntu: 34 triệu kết quả
learn centos: 0,7 triệu kết quả
www.ubuntu-vn.org/ mặc dù trang này đang chết lâm sàng, nhưng dù sao cũng làm điểm sáng cho Ubuntu

Nhìn vào các ông lớn

Mình theo dõi các hệ sinh thái của các tập đoàn công nghệ như Google, Facebook thì họ đều dùng Ubuntu làm chủ đạo, bằng việc nhìn vào các hướng dẫn build của các phần mềm, hệ thống như: V8, Chrome, ChromeOS, HHVM…

Ví dụ thực tế

Mình mất khoảng 1 tuần để cài Google V8 Javascript Engine lên Centos 6, bằng cách biên dịch mã nguồn mới nhất, nhưng KHÔNG THÀNH CÔNG. Cách duy nhất để cài được là sử dụng SCL (Software Collections)[https://www.softwarecollections.org/en/scls/rhscl/v8314/] chỉ với phiên bản 3.14. Cũng như các lần biên dịch các mã nguồn khác, lỗi thường xuyên xảy ra là bộ thư viện quá cũ, không thể biên dịch được.
Mặc dù, mình đã biên dịch thành công V8 cũng như cài đặt V8Js cho Centos 7, nhưng mà với cái vết không cài được trên Centos 6 làm mình cảm thấy không mặn mà với Centos nữa.

Kết luận

Với quan điểm nhanh của khởi nghiệp, mình khuyến nghị dùng Ubuntu vì những lợi ích cộng thêm khá lớn. Thông thường, các sản phẩm tốt đều là đa nền tảng, nhưng bắt đầu đều từ Ubuntu là chính, nếu bạn muốn phát triển cùng với hệ sinh thái nào đó.

Tham khảo

http://searchdatacenter.techtarget.com/feature/Compare-popular-Linux-distributions-for-servers
http://serverfault.com/questions/53954/centos-vs-ubuntu

The post Centos hay Ubuntu dành cho khởi nghiệp appeared first on Fullstack Station.

]]>
https://fullstackstation.com/centos-hay-ubuntu-danh-cho-khoi-nghiep/feed/ 0
Tối ưu tốc độ website bằng module pagespeed cho Nginx https://fullstackstation.com/toi-uu-toc-do-website-bang-module-pagespeed-cho-nginx/ https://fullstackstation.com/toi-uu-toc-do-website-bang-module-pagespeed-cho-nginx/#respond Sat, 09 Jan 2016 19:07:00 +0000 https://www.businesscard.vn/blog/?p=206 Tối ưu tốc độ website là gì? Để một website có nội dung động (như blog Fullstack Station này) trải qua rất nhiều bước: Viết code PHP/Python/Ruby, kết nối cơ sở dữ liệu, process engine sẽ kết hợp dữ liệu từ cơ sở dữ liệu với HTML cho ra web với giao diện hoàn thiện. Sau đó, web […]

The post Tối ưu tốc độ website bằng module pagespeed cho Nginx appeared first on Fullstack Station.

]]>
Tối ưu tốc độ website là gì?

Để một website có nội dung động (như blog Fullstack Station này) trải qua rất nhiều bước: Viết code PHP/Python/Ruby, kết nối cơ sở dữ liệu, process engine sẽ kết hợp dữ liệu từ cơ sở dữ liệu với HTML cho ra web với giao diện hoàn thiện. Sau đó, web server sẽ trả kết quả HTML/CSS/JS đã được biên dịch này về trình duyệt web (browser). Mỗi công đoạn trong quá trình trên cần được tối ưu để website đạt tốc độ tốt nhất.

Có nhiều kỹ thuật để tối ưu tốc độ website (nén file, nén hình ảnh, lazy load…), và tối ưu web server là một trong những thành phần quan trọng nhất. Mình giới thiệu đến các bạn cách cài đặt module pagespeed (mod_pagespeed) cho nginx trên Centos 7.

Chú ý: nếu bạn muốn dùng Centos nhưng chưa tự tay cài server bao giờ hoặc muốn cài đặt nhanh, mình khuyến nghị dùng CentMin Mod để cài đặt Nginx, Maria Mysql DB, PHP-FPM, Opcache, Memcached…

Giới thiệu module PageSpeed

Module PageSpeed là một dự án của Google, ở Google việc tối ưu tốc độ website là cực kỳ quan trọng. Họ luôn phát triển các công cụ, kỹ thuật để làm cho website chạy nhanh nhất có thể, có thể kể ra một vài dự án như: Google Chrome (tất nhiên có nhiều mục đích khác nữa, nhưng ít nhất nó cũng có tốc độ tải trang nhanh hơn các trình duyệt khác), Pagespeed Insights (Công cụ kiểm tra các yếu tốc tốc độ của website), mod Pagespped

Các kỹ thuật tối ưu tốc độ sẽ được giới thiệu trong loạt bài “Tối ưu tốc độ cho website”.

Nếu bạn sử dụng website bằng WordPress, thì có lẽ plugin [W3 Total Cache] cũng đủ dùng, tuy nhiên nếu bạn dùng nền tảng khác không có plugin tương tự hoặc website là do bạn viết thì bài viết này sẽ giúp ích nhiều cho bạn. Ngay cả khi dùng WordPress với W3 Total Cache thì nếu dùng thêm mod pagespeed vẫn hiệu quả hơn bạn nhé, ngoài ra còn có rất nhiều tính năng rất hay.

Kiểm tra trước khi tối ưu tốc độ

Đây là điểm số của blog trên Pingdom: (Thời điểm dùng domain businesscard.vn)

businesscard-blog-before-pagespeed

Đây là thông số hệ thống:

  • Nền tảng: WordPress 4.4
    • Plugin cache (ví dụW3 Total Cache): không hoạt động. Để dễ dàng đánh giá nên mình không bật chức năng này lên.
  • Máy chủ: Centos 7
  • Máy chủ web: Nginx 1.9.9
  • Preprocessor: PHP7 với Zend OPcache
  • HTTP/2 + SSL: hoạt động. (SSL của mình đã tối ưu mức A+ tại SSLLabs)

Mặc dù đã dùng ZendOpcache và HTTP/2 mà như bạn thấy ở hình test ở trên, chậm hơn 78% website khác đã test tại Pingdom, hix hix. Sao mà chậm quá vậy !!!

View source xem thử:

bc-blog-script-source

=> Rất nhiều file Css và Js sẽ làm cho website tải lâu hơn

businesscard-blog-source

=> Còn rất nhiều khoảng trắng và các dòng ghi chú (comment) => website sẽ nặng nên chậm hơn, đó là những thứ không cần thiết cần phải được loại bỏ.

Yah, phải khắc phục thôi!!!!!!!!!

Bắt đầu tối ưu tốc độ

Yêu cầu để thực hiện theo bài viết:

  • Máy chủ Centos 6 hoặc 7, có quyền root.
  • Máy chủ web: Nginx (Đối với các bạn dùng Apache, sẽ có bài viết khác nhé)

Bước 1: cài đặt các thư viện cần thiết

sudo yum install wget curl unzip gcc-c++ pcre-devel zlib-devel

Bước 2: tìm phiên bản mới nhất

Vào trang chủ chính thức của Nginx, bạn sẽ nhìn thấy phiên bản mới nhất, nhớ chọn phiên bản đầu tiên của Mainline version nhé. Nhớ số phiên bản này, hiện tại là 1.9.9

Bước 3: tải mã nguồn Nginx

NGINX_VERSION=1.9.9 #khai báo phiên bản Nginx đã xác định ở trên
cd /usr/src #Mình có thói quen build source từ thư mục này 
sudo wget http://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz 
sudo tar zxvf nginx-${NGINX_VERSION}.tar.gz

Bước 4: xác định phiên bản mã nguồn PageSpeed mới nhất

Vào Github Repo, vào mục Branch/Tag, sẽ thấy phiên bản mới nhất:

pagespeed-git

Theo hình trên thì phiên bản mới nhất là: v.1.10.33.2-beta [chỉ cần nhớ 1.10.33-2]

Bước 5: tải & giải nén pagespeed

NPS_VERSION=1.10.33.2 #dòng này khai báo phiên bản của Pagespeed
cd /usr/src
sudo wget https://github.com/pagespeed/ngx_pagespeed/archive/release-${NPS_VERSION}-beta.zip -O release-${NPS_VERSION}-beta.zip
unzip release-${NPS_VERSION}-beta.zip
cd ngx_pagespeed-release-${NPS_VERSION}-beta/
wget https://dl.google.com/dl/page-speed/psol/${NPS_VERSION}.tar.gz
tar -xzvf ${NPS_VERSION}.tar.gz  # extracts to psol/

Bước 6: bắt đầu build

cd /usr/src/nginx-${NGINX_VERSION}/
# vì nên bật http/2 và ssl luôn
./configure --add-module=/usr/src/ngx_pagespeed-release-${NPS_VERSION}-beta --with-http_v2_module --with-http_ssl_module
make
sudo make install
# Sau khi chạy xong, kiểm tra lại:
ls /usr/local/nginx
#Nếu thấy: "conf html logs sbin" có nghĩa là đã build xong

Bước 7: tạo script init

sudo nano /etc/init.d/nginx

Copy script này vào:

#!/bin/sh
#
# nginx - this script starts and stops the nginx daemon
#
# chkconfig:   - 85 15
# description:  NGINX is an HTTP(S) server, HTTP(S) reverse 
#               proxy and IMAP/POP3 proxy server
# processname: nginx
# config:      /etc/nginx/nginx.conf
# config:      /etc/sysconfig/nginx
# pidfile:     /var/run/nginx.pid

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0

nginx="/usr/sbin/nginx"
prog=$(basename $nginx)

NGINX_CONF_FILE="/etc/nginx/nginx.conf"

[ -f /etc/sysconfig/nginx ] && . /etc/sysconfig/nginx

lockfile=/var/lock/subsys/nginx

make_dirs() {
   # make required directories
   user=`$nginx -V 2>&1 | grep "configure arguments:" | sed 's/[^*]*--user=([^ ]*).*/1/g' -`
   if [ -z "`grep $user /etc/passwd`" ]; then
       useradd -M -s /bin/nologin $user
   fi
   options=`$nginx -V 2>&1 | grep 'configure arguments:'`
   for opt in $options; do
       if [ `echo $opt | grep '.*-temp-path'` ]; then
           value=`echo $opt | cut -d "=" -f 2`
           if [ ! -d "$value" ]; then
               # echo "creating" $value
               mkdir -p $value && chown -R $user $value
           fi
       fi
   done
}

start() {
    [ -x $nginx ] || exit 5
    [ -f $NGINX_CONF_FILE ] || exit 6
    make_dirs
    echo -n $"Starting $prog: "
    daemon $nginx -c $NGINX_CONF_FILE
    retval=$?
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}

stop() {
    echo -n $"Stopping $prog: "
    killproc $prog -QUIT
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}

restart() {
    configtest || return $?
    stop
    sleep 1
    start
}

reload() {
    configtest || return $?
    echo -n $"Reloading $prog: "
    killproc $nginx -HUP
    RETVAL=$?
    echo
}

force_reload() {
    restart
}

configtest() {
  $nginx -t -c $NGINX_CONF_FILE
}

rh_status() {
    status $prog
}

rh_status_q() {
    rh_status >/dev/null 2>&1
}

case "$1" in
    start)
        rh_status_q && exit 0
        $1
        ;;
    stop)
        rh_status_q || exit 0
        $1
        ;;
    restart|configtest)
        $1
        ;;
    reload)
        rh_status_q || exit 7
        $1
        ;;
    force-reload)
        force_reload
        ;;
    status)
        rh_status
        ;;
    condrestart|try-restart)
        rh_status_q || exit 0
            ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload|configtest}"
        exit 2
esac

Cho phép script quyền thực thi:

sudo chmod +x /etc/init.d/nginx

Nếu trường hợp bạn đang sử dụng nginx đã cài bằng lệnh yum rồi:

#backup phiên bản nginx đang chạy
sudo mv /usr/sbin/nginx /usr/sbin/nginx.yum

Cài đặt vào thư mục sbin:

sudo ln -fs /usr/local/nginx/sbin/nginx /usr/sbin/nginx

Cài đặt cấu hình:

sudo ln -s /usr/local/nginx/conf/ /etc/nginx
# dùng để server tự bật nginx lên sau khi restart sudo chkconfig nginx on

Sau bước này, bạn đã cài đặt xong Nginx + mod Pagespeed, bây giờ chỉ việc kích hoạt lên

Bước 8: Kích hoạt mod pagespeed

sudo mkdir -p /var/ngx_pagespeed_cache
#user nginx được lấy trong file /etc/nginx/nginx.conf, có thể của bạn là nobody
sudo chown -R nginx:nginx /var/ngx_pagespeed_cache

Thêm các dòng sau vào trong block server của nginx.conf:

##
# Pagespeed main settings

pagespeed on;
pagespeed FileCachePath /var/ngx_pagespeed_cache;

# Ensure requests for pagespeed optimized resources go to the pagespeed
# handler and no extraneous headers get set.

location ~ ".pagespeed.([a-z].)?[a-z]{2}.[^.]{10}.[^.]+" { add_header "" ""; }
location ~ "^/ngx_pagespeed_static/" { }
location ~ "^/ngx_pagespeed_beacon" { }

 # Filter settings
pagespeed RewriteLevel CoreFilters;
pagespeed EnableFilters collapse_whitespace,remove_comments,combine_css,rewrite_css,combine_javascript,rewrite_javascript;

Nếu bạn add như trên vào nginx, thì tất cả các website đều được bật pagespeed, nếu bạn muốn chỉ một vài website đặc biệt chạy mod pagespeed thì đừng thêm vào nginx.conf mà thêm vào file config của website đặc biệt đó ví dụ: /etc/nginx/conf.d/www.example.conf

Start nginx

sudo service nginx start

Cuối cùng kiểm tra thành quả:

bc-after-ps

Oh, đã nhanh hơn 46% rồi đó. (Phần nội dung website đã giảm từ 1.6MB xuống ~900KB)

Để hiểu hết ý nghĩa của các bộ lọc này, bạn đọc thêm bài viết Ý nghĩa của các bộ lọc trong module Pagespeed và cách sử dụng để tối ưu hóa tốc độ website

Kết luận:

Từ chậm hơn 78% lên mức nhanh hơn 46% quả là không tệ phải không bạn? Tuy nhiên đây chưa phải là mức cao mà Fullstack Station nhắm đến, nếu các bạn thực hiện hết tất cả các tiêu chuẩn kỹ thuật mà seri “Tối ưu hóa tốc độ website” mang lại, mình đảm bảo tốc độ sẽ nằm ở mức “nhanh hơn 80%

The post Tối ưu tốc độ website bằng module pagespeed cho Nginx appeared first on Fullstack Station.

]]>
https://fullstackstation.com/toi-uu-toc-do-website-bang-module-pagespeed-cho-nginx/feed/ 0
Ý nghĩa và cách sử dụng bộ lọc của Pagespeed https://fullstackstation.com/y-nghia-trong-danh-sach-bo-loc-cua-pagespeed-va-cach-su-dung/ https://fullstackstation.com/y-nghia-trong-danh-sach-bo-loc-cua-pagespeed-va-cach-su-dung/#respond Sat, 09 Jan 2016 01:48:38 +0000 https://www.businesscard.vn/blog/?p=213 Trang chủ pagespeed cho Nginx: http://ngxpagespeed.com/ Cách bật tắt: # Bật pagespeed on; # Tắt pagespeed off; Cách thêm hoặc bớt bộ lọc (filter): # Khai báo một dòng pagespeed EnableFilters filter_1,filter_2,...,module_2; # Khai báo nhiều dòng pagespeed EnableFilters filter_1,filter_2,...,module_2; pagespeed EnableFilters filter_1,filter_2,...,module_2; Danh sách các bộ lọc của Google Pagespeed rất nhiều nên ở đây mình […]

The post Ý nghĩa và cách sử dụng bộ lọc của Pagespeed appeared first on Fullstack Station.

]]>
Trang chủ pagespeed cho Nginx: http://ngxpagespeed.com/

Cách bật tắt:

# Bật
pagespeed on;
 
# Tắt
pagespeed off;

Cách thêm hoặc bớt bộ lọc (filter):

# Khai báo một dòng
pagespeed EnableFilters filter_1,filter_2,...,module_2;
 
# Khai báo nhiều dòng
pagespeed EnableFilters filter_1,filter_2,...,module_2;
pagespeed EnableFilters filter_1,filter_2,...,module_2;

Danh sách các bộ lọc của Google Pagespeed rất nhiều nên ở đây mình sẽ liệt kê ra các bộ lọc thường dùng, dễ hiểu nhất để các bạn tham khảo. Ngoài ra các bạn nên tham khảo qua danh sách toàn bộ bộ lọc có ở trang chủ Pagespeed tại đây.

  • combine_heads
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Tự gộp nếu website có nhiều thẻ <head> được tìm thấy trong tài liệu.
  • inline_import_to_link
    • CoreFilters: Yes
    • OptimizeForBandwidth: No
    • Tự tạo một tập tin CSS và chèn vào thẻ <link> nếu website chứa thẻ <style> và trong đó có sử dụng @import.
  • outline_css
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Gộp các đoạn CSS được chèn trực tiếp vào website ở thẻ <style> vào một file CSS đệm và chèn vào thẻ <link>.
  • outline_javascript
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Gộp các đoạn Javascript được chèn trực tiếp vào website ở thẻ <script> vào một file JS đệm và chèn vào thẻ <link>.
  • move_css_above_scripts
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Tự động đưa toàn bộ CSS của website lên trên các đoạn Javascript, hay nói cách khác là ép website tải CSS trước khi tải Javascript.
  • combine_css
    • CoreFilters: Yes
    • OptimizeForBandwidth: No
    • Tự nén nhiều file CSS vào trong một file CSS chung để giảm số lượng request trong website.
  • rewrite_css
    • CoreFilters: Yes
    • OptimizeForBandwidth: Yes
    • Rewrite lại CSS – việc rewrite này sẽ tối ưu CSS bằng cách tự bỏ các đoạn comment, xóa khoảng trắng, lưu cache cho các file ảnh có trong CSS,…
  • rewrite_style_attributes
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Kích hoạt rewrite cho các đoạn CSS nằm trong một thẻ nào được được khai báo bằng tham số style=”…”.
  • flatten_css_imports
    • CoreFilters: Yes
    • OptimizeForBandwidth: No
    • Tách nội dung của một file CSS được chèn vào bằng thẻ @import vào thẻ <style>.
  • prioritize_critical_css
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Tự động tách các thành phần CSS quan trọng trong website và đưa lên đầu website để nó tải trước.
  • make_google_analytics_async
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Tự động chuyển đoạn mã theo dõi của Google Analytics về kỹ thuật tải không đồng bộ (async). Tức là chỉ tải sau khi website tải xong CSS.
  • rewrite_javascript
    • CoreFilters: Yes
    • OptimizeForBandwidth: Yes
    • Rewrite lại Javascript – việc rewrite sẽ giúp nén file .js lại bằng cách bỏ comment, bỏ khoảng trắng.
  • combine_javascript
    • CoreFilters: Yes
    • OptimizeForBandwidth: No
    • Gộp nhiều file .js thành một file .js chung để giảm thời gian tải.
  • canonicalize_javascript_libraries
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Tự động sử dụng các thư viện trên CDN của Google nếu có. Ví dụ website bạn đang sử dụng file jquery.js tự host thì nó sẽ tự chuyển sang file jquery.js trên CDN của Google.
  • inline_css
    • CoreFilters: Yes
    • OptimizeForBandwidth: No
    • Tự chuyển nội dung file CSS trong website ra ngoài tài liệu và chèn vào thẻ <style> trong website.
  • inline_google_font_css
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Tự động chuyển các thẻ chèn Google Font vào website thành định dạng font cố định .woff.
  • inline_javascript
    • CoreFilters: Yes
    • OptimizeForBandwidth: No
    • Tự chuyển nội dung Javascript trong các file .js và chèn trực tiếp vào tài liệu bằng thẻ <script>.
  • local_storage_cache
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Tự lưu nội dung của website như một bản bộ nhớ đệm là tiến hành load ra ở lần truy cập sau.
  • insert_ga
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Tự thêm mã nhúng Google Analytics vào mỗi trang của website.
  • rewrite_images
    • CoreFilters: Yes
    • OptimizeForBandwidth: Yes
    • Tối ưu lại hình thành bằng cách rewrite lại đường dẫn, nén ảnh về định dạng webp, giảm dung lượng ảnh và thêm thời hạn cache cho ảnh.
  • convert_jpeg_to_progressive
    • CoreFilters: Yes
    • OptimizeForBandwidth: Yes
    • Tự động chuyển tất cả hình ảnh định dạng JPEG sang định dạng nén.
  • convert_png_to_jpeg
    • CoreFilters: Yes
    • OptimizeForBandwidth: Yes
    • Chuyển tất cả hình ảnh định dạng PNG sang JPEG.
  • convert_jpeg_to_webp
    • CoreFilters: Yes
    • OptimizeForBandwidth: Yes
    • Chuyển tất cả hình ảnh từ định dạng JPEG sang Webp.
  • insert_image_dimensions
    • CoreFilters: Yes
    • OptimizeForBandwidth: Yes
    • Tự thêm tham số width và height vào thẻ <img>.
  • inline_images
    • CoreFilters: Yes
    • OptimizeForBandwidth: Yes
    • Chuyển các hình ảnh cỡ nhỏ về định dạng base64.
  • convert_gif_to_png
    • CoreFilters: Yes
    • OptimizeForBandwidth: Yes
    • Chuyển đổi hình ảnh định dạng GIF về PNG.
  • resize_images
    • CoreFilters: Yes
    • OptimizeForBandwidth: No
    • Thay đổi kích thước hình ảnh.
  • resize_mobile_images
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Thay đổi kích thước hình ảnh nhưng chỉ có hiệu lực khi truy cập bằng các trình duyệt trên điện thoại di động.
  • remove_comments
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Xóa các đoạn comment trong mã nguồn HTML của website.
  • collapse_whitespace
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Xóa các khoảng trắng bên trong mã nguồn HTML của website.
  • sprite_images
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Tự động cắt nhỏ hình ảnh background ra và ráp vào mã nguồn HTML bằng CSS để giảm thời gian tải bằng cách tải luân phiên từng mảnh trong ảnh đã được cắt, kỹ thuật này gọi là Sprite Image.
  • defer_javascript
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Thiết lập website chỉ tải Javascript sau khi các thành phần trong website đã tải xong.
  • lazyload_images
    • CoreFilters: No
    • OptimizeForBandwidth: No
    • Thêm hiệu ứng LazyLoad cho toàn bộ ảnh trong website (kỹ thuật chỉ load ảnh khi kéo thanh cuộn website xuống tới thành phần chứa ảnh).

Những tính năng trên không phải cứ bật là chạy, nó còn tùy thuộc vào code của website nữa, có nhiều trường hợp minify javascript sẽ khiến javascript trên website của bạn bị lỗi, vì do javascript đó viết không tốt.

Tốt hơn hết, là bạn cứ thử bật/tắt từng bộ lọc để xem website có lỗi không nhé.

The post Ý nghĩa và cách sử dụng bộ lọc của Pagespeed appeared first on Fullstack Station.

]]>
https://fullstackstation.com/y-nghia-trong-danh-sach-bo-loc-cua-pagespeed-va-cach-su-dung/feed/ 0
Cài đặt SSL và giao thức HTTP/2 cho NGINX trên CentOS 7 https://fullstackstation.com/cai-dat-ssl-va-giao-thuc-http2-cho-nginx-tren-centos-7/ https://fullstackstation.com/cai-dat-ssl-va-giao-thuc-http2-cho-nginx-tren-centos-7/#respond Thu, 01 Oct 2015 02:03:00 +0000 https://www.businesscard.vn/blog/?p=84 Trong tháng 2/2015, một kiểu giao thức web mới vừa được IESG chấp thuận mang nhiều tính năng vượt trội hơn, giúp website tối ưu tốc độ hơn đó là giao thức HTTP/2. Vậy thì HTTP/2 là gì, nó có những ưu điểm nào thì trong bài này, tác giả Công Hải tại AppFast sẽ […]

The post Cài đặt SSL và giao thức HTTP/2 cho NGINX trên CentOS 7 appeared first on Fullstack Station.

]]>
Trong tháng 2/2015, một kiểu giao thức web mới vừa được IESG chấp thuận mang nhiều tính năng vượt trội hơn, giúp website tối ưu tốc độ hơn đó là giao thức HTTP/2. Vậy thì HTTP/2 là gì, nó có những ưu điểm nào thì trong bài này, tác giả Công Hải tại AppFast sẽ giới thiệu và hướng dẫn cách cài đặt nó vào máy chủ Linux sử dụng CentOS 7.

Cập nhật 12/2019: vào 01/2020 thì 2 giao thức TLSv1 TLSv1.1 trở nên lỗi thời và không còn đạt điểm bảo mật cao nhất nữa, vì vậy bạn cần phải điều chỉnh lại thiết lập cho phù hợp để đạt điểm A+.

HTTP 1.1 và HTTP 2

HTTP (Hypertext Transfer Protocol) là một giao thức truyền chuẩn về mạng (truyền tải siêu văn bản – nói nôm na là giao thức web). HTTP 1.1 ra đời vào năm 1997 và vẫn được sử dụng đến hiện tại mà chưa hề có một nâng cấp nào. Có lẽ đã quá cũ nên vào 12/2014 nhóm phát triển của Hypertext Transfer Protocol đã đề xuất lên IESG xem HTTP/2 như là một tiêu chuẩn mới. Và đã được IESG chấp thuận vào ngày 17/02/2015.

HTTP 2 phát triển dựa trên SPDY (pronounced speedy) một giao thức mạng mở được phát triển bởi Google.

Sự khác biệt thì rất nhiều nhưng mình tóm lại sự khác biệt lớn nhất giữa 2 giao thức là: HTTP2 hỗ trợ các truy vấn ghép, nén nội dung, ưu tiên và quản lý thông minh hơn các luồng dữ liệu. Điều đó gây ra việc giảm độ trễ và tăng tốc tải nội dung web. Xem thêm tại bài HTTP/2 là gì?

HTTPS là gì?

HTTPS (Hypertext Transfer Protocol Secure) là một sự kết hợp giữa giao thức HTTP và giao thức bảo mật SSL hay TLS cho phép trao đổi thông tin một cách bảo mật trên Internet.

Cách cài đặt

Hiện có rất nhiều bài hướng dẫn cài đặt SSL nhưng thật sự rất ít bài làm đúng. Ngay cả tinhte.vn cũng chưa thực sự cài đúng.

Các bạn có thể test SSL của website tại:https://www.ssllabs.com/ssltest/index.html

Kết quả test của https://fullstackstation.com/.

Nên hôm nay, mình sẽ hướng dẫn bạn cài đặt và cấu hình HTTPS với HTTP2 lên chuẩn A+.

Bước 1. Cài NGINX 1.9.5 trở lên và kích hoạt HTTP 2

Ngày 22/09/2015 vừa rồi NGINX đã ra phiên bản mainline 1.9.5 chính thức hỗ trợ HTTP 2, và từ này chính thức say goodbye SDPY một thời hùng hậu. Như vậy, điều này có nghĩa là bạn chỉ có thể sử dụng HTTP 2 trên NGINX phiên bản 1.9.5 trở lên, nếu bạn đang dùng NGINX thì hãy gõ nginx -v để kiểm tra phiên bản NGINX hiện tại của bạn.

Để cài NGINX 1.9.5, bạn cần nạp package vào. Hãy tạo file /etc/yum.repos.d/nginx.repo và chèn đoạn dưới đây vào hoặc nếu có rồi thì sửa nội dung:
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

Sau đó cập nhật lại gói yum.

yum update -y

Và cài NGINX vào với lệnh sau:

yum install nginx

Sau khi cài đặt bạn kiểm tra lại có phải là version 1.9.5 và có module http 2 (--with-http_v2_module) bằng lệnh sau:

nginx -V

Sau khi cài đặt xong, hãy thiết lập NGINX sử dụng HTTP 2 bằng cách mở tập tin cấu hình NGINX của bạn tại /etc/nginx/conf.d và đổi phần listen 80 thành thế này:

server {
 listen 443 ssl http2;
 server_name domain.com www.domain.com;
 .....
}

Bước 2: Cấu hình SSL cho NGINX

Thiết lập chứng thực vùng nhớ (Session cache)

Điều này là khá quan trọng vì khi truy cập giao thức SSL thì lần đầu sẽ xử lý rất nặng và nhiều (Nên khi truy cập vào trang web https lần đầu tiên thường lâu hơn so với lần sau). Thiết lập này sẽ giúp NGINX nhớ session của user và  không cần chứng thực cho request kế tiếp.

ssl_session_cache shared:SSL:20m;
ssl_session_timeout 180m;

Ý nghĩa dòng 1 là tạo vùng nhớ 20MB cho chứng thực SSL. Theo tài liệu của NGINX thì 1MB chứ 4000 session. Vậy 20MB tương đương với 80.000 Session (bạn có thể điều chỉnh cho phù hợp với nhu cầu server bạn).

Dòng thứ 2 là lưu nó trong 180 phút (3 tiếng) con số này phù hợp với khoảng thời gian User truy cập website bạn. Nếu website bạn cần bảo mật hơn thì có thể giảm con số này xuống nhưng KHÔNG NÊN giảm dưới 10 phút.

Vô hiệu hóa SSL

Có thể là bạn nói tôi khùng, đang setup SSL giờ là vô hiệu hóa nó.

Nói vậy thôi, chứ thực ra là thay thế SSL (Secure Sockets Layer) bằng TLS(Transport Layer Security). Vì thực tế là SSL còn nhiều điểm yếu hơn là TLS. Tuy nhiên IE6 không hỗ trợ TLS (nhưng chắc là IE6 đã quá cổ rồi, tìm cũng chẳng còn đâu).

Thêm dòng sau tiếp theo 2 dòng trên:

ssl_protocols TLSv1.2;
# từ 02/2020 thì TLSv1 TLSv1.1 đưa vào danh sách lạc hậu, bạn cần chỉnh lại giá trị này

Tối ưu hóa Cipher Suites (Bộ mã hóa)

Trung tâm xử lý, mã hóa, giải mã của SSL/TLS là chổ này (tạm hiểu vậy vì mình không phân tích sâu vào cơ chế hoạt động của nó).

Khai báo NGINX bật bộ mã hóa:

ssl_prefer_server_ciphers on;

Khai báo danh sách các cơ chế mã hóa được chấp nhận:

ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5

Tạo ra các thông số DHParam

Tạo file DH (Diffie-Hellman) với 2048 bit (đủ chết cho những thằng muốn hack):

openssl dhparam 2048 -out /etc/nginx/cert/dhparam.pem

Sau đó thêm vào config dòng sau:

ssl_dhparam /etc/nginx/cert/dhparam.pem;

@Lưu ý: Nếu client của bạn dùng JAVA 6 trở xuống thì nên dùng 1024 bit thôi nhé ?

Kích hoạt OCSP

OCSP (Online Certificate Status Protocol) được hiểu như là kiểm tra chứng thức của bạn với nhà cùng cấp SSL (theo bài tạo chứng chỉ SSL đây là COMODO). Tạo ra file Khai báo với NGINX của bạn đây là giấy thức bằng cách sử dụng lệnh sau:

cat AddTrustExternalCARoot.crt PositiveSSLCA2.crt > trustchain.crt

File AddTrustExternalCARoot.crt là file gốc, file PositiveSSLCA2.crt là file chứng thực trung gian có kèm theo trong file zip khi bạn mua SSL hoặc download của COMODO tại đây.

Tiếp theo là cấu hình NGINX stapling

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/cert/trustchain.crt;
resolver 8.8.8.8 8.8.4.4;

Ở đây là mình dùng qua DNS Google, bạn có thể dùng DNS nào khác mà bạn tin tưởng hoặc nhanh hơn.

Cấu hình Strict Transport Security

Sau khi server đã chứng thực xong thì trả về trình duyệt thời gian chứng thực được chấp nhận, trong thời gian này khi request trình duyệt không cần gửi chứng thực với Server nữa (Dó là lý do tại sao chỉ nặng lúc đầu).

Thêm dòng sau vào config file:

add_header Strict-Transport-Security "max-age=31536000" always;

Trong trường hợp chứng thực này được dùng cho nhiều subdomain thì sửa lại như sau:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

That All, chỉ thế thôi. Bạn save lại file và restart NGINX và có thể kiểm tra xem SSL của bạn được loại gì rồi nào?

Sau khi cấu hình xong bạn sẽ có file cấu hình NGINX của domain như thế này đây:

server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 
 server_name your_domain.com;
 
 ssl_certificate /etc/nginx/cert/your_key.certchain.crt;
 ssl_certificate_key /etc/nginx/cert/your_key.key;
 
 ssl_session_cache shared:SSL:20m;
 ssl_session_timeout 60m;
 
 ssl_prefer_server_ciphers on;
 ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
 
 ssl_dhparam /etc/nginx/cert/dhparam.pem;
 
 ssl_protocols TLSv1.2;
  
 ssl_stapling on;
 ssl_stapling_verify on;
 ssl_trusted_certificate /etc/nginx/cert/trustchain.crt;
 resolver 8.8.8.8 8.8.4.4;
 
 add_header Strict-Transport-Security "max-age=31536000" always;
 #add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
 
 # Cấu hình của bạn ở dưới này
 …
}

Sau đó bạn có thể kiểm tra server đã dùng HTTP 2 chưa bằng cách cài pluginHTTP/2 and SPDY indicator của Chrome.

Thế thôi, rất đơn giản phải không nào? Nhìn chung cách cài đặt SSL và bật HTTP/2 cũng khá đơn giản, nó cũng giống như mình kích hoạt SPDY mà thôi nhưng chỉ khác là thay spdy thành http2 trong phần listen của tập tin cấu hình mà thôi. Nhưng ngoài việc đó, trong bài này bạn cũng đã biết thêm một vài kỹ thuật quan trọng để cấu hình SSL an toàn hơn để đạt chuẩn A+ tại SSLLabs.

Nguồn: Bài viết được gởi từ tác giả Công Hải từ appfast.io là đối tác của Fullstack Station. Được biên tập và cập nhật bởi Fullstackstation.

The post Cài đặt SSL và giao thức HTTP/2 cho NGINX trên CentOS 7 appeared first on Fullstack Station.

]]>
https://fullstackstation.com/cai-dat-ssl-va-giao-thuc-http2-cho-nginx-tren-centos-7/feed/ 0