Home » Posts tagged "standard"

RFC 8446:TLS 1.3

看到 RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3) 正式推出了,也就是 TLS 1.3 正式成為 IETF 的標準 (Standards Track)。

Cloudflare 寫了一篇文章「A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)」描述了 TLS 1.3 的特點,有興趣的人可以看一看,尤其是 1-RTT 的部份對效能幫助很大 (0-RTT 因為 replay attack 問題,我應該暫時都不會考慮,要等到有一個合理的防禦模型出來)。

另外一個是 OpenSSL 目前最新版是 1.1.0h,當初就決定要等 TLS 1.3 正式成為標準才會出 1.1.1 (參考「OpenSSL 1.1.1 將支援 TLS 1.3」,這也熬了一年啊... 支援後會就有很多軟體可以直接套用了,可以來期待了。

GCP 的 f1-micro 的使用心得...

這幾天在弄備援跳板機,不想弄在日本 (latency),所以就想到 Google Cloud Platform (GCP) 在台灣有機房,而 Compute Enginef1-micro,類似 AWSEC2 提供的 t2.nano 的機器。而這兩天玩了玩,大概有些事情值得記錄起來。

CPU 相關的部份:

  • EC2 的 t2 系列可以透過 API 或是在 web console 看到 CPU credit 剩下多少,GCE 沒找到在哪邊可以看。
  • EC2 的 t2 系列在 CPU credit 用完後是變慢運行,除非你打開 T2 Unlimited 同意 AWS 多收錢。而 GCE 的則是沒得選,相當於一定要開 T2 Unlimited。
  • GCE 的 f1-micro 是 0.2 vCPU,但我在上面跑 Ubuntu 18.04,平常沒事就已經是 15% 左右。這數字比預期的高不少,還在找是什麼原因...

網路相關的部份:

  • 因為要用台灣的機房,網路的部份只有 Premium 等級可以選 (Standard 等級目前只在美國有),也就是會先走 Google 佈建的網路再出去,所以流出的費用會隨著 destination 地區而有差異 (i.e. 封包送到美國與送到中國是不同計價)。
  • 但 Premium 等級實測品質真的很不一樣,到香港居然在 15ms 以下,以前在固網機房內沒看過這個數字...

其他的部份:

  • 硬碟空間方面,Standard provisioned space 比 EBSgp2 便宜不少,而且還包括了 i/o 費用 (AWS 會另外收費)
  • 連續使用就會有 discount 了,也可以 commit 買一年或是三年取得更深的 discount。而 AWS 則是得買 Reserved Instance 拿到 discount。

來看看一個月會有多少帳單產生吧...

AWS 推出 EC2 Fleet:直接混搭標準 EC2、Spot、RI 的計算

AWS 將本來 EC2Spot Fleet 加上了 EC2 Fleet,計算的公式從本來只有 Spot Instace,變成把標準 EC2 Instance 與 RI 的計算全部都納進來:「EC2 Fleet – Manage Thousands of On-Demand and Spot Instances with One Request」。

Today we are extending and generalizing the set-it-and-forget-it model that we pioneered in Spot Fleet with EC2 Fleet, a new building block that gives you the ability to create fleets that are composed of a combination of EC2 On-Demand, Reserved, and Spot Instances with a single API call.

不過目前有些服務還沒整,主要是跟 auto scaling 有關的部份,這部份應該是一次上一大包:

We plan to connect EC2 Fleet and EC2 Auto Scaling groups. This will let you create a single fleet that mixed instance types and Spot, Reserved and On-Demand, while also taking advantage of EC2 Auto Scaling features such as health checks and lifecycle hooks. This integration will also bring EC2 Fleet functionality to services such as Amazon ECS, Amazon EKS, and AWS Batch that build on and make use of EC2 Auto Scaling for fleet management.

整完以後對於要省成本就更簡單了...

t2 系列機器的 CPU credit 超出 Quota 的現象

在看 CPU credit 時發現 EC2 上有台 t2.micro CPU credit 一直掉,但是上面沒有跑什麼東西,所以先在內部的 Trac 上開張 ticket 追蹤... 然後這種事情都是一開 ticket 就馬上想到了 @_@

首先發現這些 CPU credit 是超出 max quota 144 的限制 (參考 AWS 的文件「CPU Credits and Baseline Performance」),就馬上想到是因為 t2 系列的機器在開機時會贈送 CPU credit 以避免開機時太慢 (參考文件「T2 Standard」),而贈送的這塊會優先使用,但不吃 max quota:

Launch credits are spent first, before earned credits. Unspent launch credits are accrued in the CPU credit balance, but do not count towards the CPU credit balance limit.

另外系統對每個帳號有限制,每個帳號每 24 小時在每區有 100 次的贈送限制:

There is a limit to the number of times T2 Standard instances can receive launch credits. The default limit is 100 launches or starts of all T2 Standard instances combined per account, per region, per rolling 24-hour period.

新帳號可能會更低,隨著使用情況調昇:

New accounts may have a lower limit, which increases over time based on your usage.

所以就知道為什麼會緩緩下降了,在到 144 之前都應該是下降的趨勢...

Amazon S3 推出新的等級 One Zone-IA

Amazon S3 有 RRS,提供給那些掉了可以重新產生的資料使用 (像是縮圖);另外也有 IA,提供給不常存取的資料使用。現在推出的這個等級結合了兩者,使得價錢更低:「Amazon S3 Update: New Storage Class and General Availability of S3 Select」。

New S3 One Zone-IA Storage Class – This new storage class is 20% less expensive than the existing Standard-IA storage class. It is designed to be used to store data that does not need the extra level of protection provided by geographic redundancy.

TLS 1.3 進入 Proposed Standard

最近蠻熱的一個新聞,TLS 1.3 的 draft-ietf-tls-tls13-28.txt 進入 Proposed Standard 了 (在「draft-ietf-tls-tls13-28 - The Transport Layer Security (TLS) Protocol Version 1.3」這邊可以看到歷史記錄):「Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)」。

沒意外的話這就會是最終版本了。如果要看 TLS 1.2 與 TLS 1.3 的差異,看維基百科上的 Transport Layer Security - TLS 1.3 會比較清楚。

大家等很久了... 像是 OpenSSL 1.1.1 其實一部分也是在等 TLS 1.3 正式推出:(出自「Using TLS1.3 With OpenSSL」)

OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised. In the meantime the OpenSSL git master branch contains our development TLSv1.3 code which can be used for testing purposes (i.e. it is not for production use).

主要還是期待非 NSA 派系的 cipher (其實幾乎都是 djb 的戰果) 與 1-RTT handshake,後續等 TLS 1.3 變成 Standard Track 應該就會被各家瀏覽器開預設值了...

新出的 RFC 8259:The JavaScript Object Notation (JSON) Data Interchange Format

JSON 的規格書又被更新了 XD

在「The Last JSON Spec」這邊,Tim Bray 寫了這篇關於新的 RFC 8259 跟之前的差異,以及大家對於雙重標準的顧慮。

最大的差異在於,在 RFC 8259 規定了「如果 JSON 被用在非封閉的系統交換資料,必須使用 UTF-8」:

8259 con­tains one new sen­tence: “JSON text ex­changed be­tween sys­tems that are not part of a closed ecosys­tem MUST be en­cod­ed us­ing UTF-8 [RFC3629].” Giv­en that, by 2017, an at­tempt to ex­change JSON en­cod­ed in any­thing but UTF-8 would be ir­ra­tional, this hard­ly needs say­ing; but its ab­sence felt like an omis­sion.

而關於 ECMA-404 與 RFC 8259 都定義了 JSON 的問題他也說明了,因為很多人花了很多力氣在確保這兩份文件的正確性上,所以應該不會有問題 (i.e. 衝突):

The rea­son 8259 ex­ists is that the ECMAScript gang went and wrote their own ex­treme­ly min­i­mal spec, Stan­dard ECMA-404: The JSON Da­ta In­ter­change Syn­tax, and there was rea­son for con­cern over du­el­ing stan­dard­s. But, af­ter a cer­tain amount of standards-org elephant-gavotte, each of ECMA 404 and RFC 8259 nor­ma­tive­ly ref­er­ences the oth­er and con­tains a com­mit­ment to keep them con­sis­tent in case any er­rors turn up. Which is a good thing, but this text has been re-examined and re-polished so many times that I doubt ei­ther side will ev­er re­vis­it the ter­ri­to­ry, thank good­ness.

另外他也提到了對於不同情境下可以看不同的文件。像是要了解 JSON 的話,可以看當初發明 JSON 的 Doug Crockford 所設立的網站 (在「JSON」這邊);而在交換時應該參考 I-JSON (Internet JSON,RFC 7493):

Which spec should you use? · If you want to un­der­stand JSON syn­tax, you still can’t beat Doug Crockford’s orig­i­nal for­mu­la­tion at JSON.org. If you want to use an RFC as foun­da­tion for a REST API or some oth­er In­ter­net pro­to­col, I ac­tu­al­ly don’t rec­om­mend 8259, I rec­om­mend I-JSON, RFC 7493, which de­scribes ex­act­ly the same syn­tax as all the oth­er specs (by ref­er­enc­ing 7159), but ex­plic­it­ly rules out some legal-but-dumbass things you could do that might break your pro­to­col, for ex­am­ple us­ing any­thing but UTF-8 or hav­ing du­pli­cate mem­ber names in your ob­ject­s.

I-JSON 是 JSON 的子集合,比較重要的:

  • (MUST) 使用 UTF-8。
  • (SHOULD NOT) 浮點數的部份,不得超過 IEEE 754-2008 binary64 (double precision) 的範圍。
  • (SHOULD NOT) 整數的部份,不得超過 [-(2**53)+1, (2**53)-1]) 的範圍。
  • (RECOMMEND) 有超過的需求使用字串表示。
  • (MUST NOT) JSON object 內不得有重複的 name。
  • (SHOULD NOT) 最上層的型態不得使用字串,只能使用 object 或是 array。
  • (MUST NOT) 遇到先前沒有定義過的元素不得視為錯誤。(像是新版 API 內會在 object 裡增加元素)
  • (RECOMMEND) 時間使用 ISO 8601 表示 (在 RFC 3339 有提到),英文字的部份全部使用大寫,一定要標上時區,而秒數的 0 一定要加上去 (也就是 00 秒)。
  • (RECOMMEND) 時間長度也建議依照 RFC 3339 處理。
  • (RECOMMEND) Binary 資料用 base64url 傳 (RFC 4648)。

HTML 5.2?

W3C 推出 HTML 5.2,新的 W3C Recommendation...

但網頁開發已經沒有人在管 W3C 的 HTML X.Y 了 (像是之前的 HTML 5.1),大家都是直接翻資料查某個 feature 的支援度來決定能不能用,像是翻 Can I use... 或是翻 MDN

就隨便看看吧... o_o

Archives