TCP Handshake - Maximum Segment Size (MSS)

Maximum Segment Size (MSS)
MSS iki taraf arasındaki bağlantıda, bir IP paketine sığdırılabilecek en büyük TCP paketi anlamına gelir. MSS sadece TCP'de vardır. UDP'de yoktur. Açıklaması şöyle. 

.. and then there's TCP MSS, which helps in case of TCP, but of course not with UDP nor ICMP.

Using the MSS field in the TCP header (only in the SYN and SYN-ACK packets of the initial 3-way handshake), hosts can signal to their peers how large a TCP payload is acceptable to receive.

TCP MSS negotiation can be a blessing, but also a nuisance, as it helps to hide MTU problems until something with large UDP packets comes along and fails at the "all hosts on the common L2 segment need to use the same MTU" criterium

Her iki taraf ta MSS değerini Bildirir ve Küçük Olanı Kullanılır

Açıklaması şöyle 

both hosts announce the MSS independently in the SYN and the SYN/ACK packets and the smaller of the two is chosen for all segments exchanged during the entire duration of the connection.

Otomatik MSS Hesaplama

Dynamic Path MTU Discovery özelliği etkinse, IP seviyesinde en büyük MTU değeri biliniyor demektir. MSS bu MTU değeri kullanılarak hesaplanır.

Örnek
Örneğin Maximum Transmission Unit 1500 byte kabul edilirse, 20 byte IP ve 20 byte TCP zarflaması çıkarılırsa MSS 1460 byte olur.

MSS = 1500 - 20 - 20
MSS = 1460 bytes of TCP data

Kendi arayüzlerimizin MTU değerlerini öğrenmek için şöyle yaparız

MSS Değerini Kodla Atamak

Şöyle yaparız

int mss = 1200; // Desired MSS value
// Set MSS for the socket
if (setsockopt(sockfd, IPPROTO_TCP, TCP_MAXSEG, &mss, sizeof(mss)) < 0) {
  perror("Setting MSS failed");
  close(sockfd);
  return 1;
}

Kodla Atanırsa MSS Her Zaman MTU'da Küçük Olmalı

Açıklaması şöyle. MSS değeri MTU'dan küçük olmalı. Eğer MTU'dan büyük TCP paketleri kullanılırsak çok fazla fragmentation olur ve verim düşer.

TCP itself uses the MSS to determine the segment size, which should fit the MTU, but I have seen people do stupid things like set the MSS to much larger than the MTU (thinking it will increase the speed, but the effect is the opposite). That forces IP to create fragments prior to sending.

MSS Olarak 1460

Açıklaması şöyle. 1460 eskidendi artık bu değer 1448 oldu

The value 1460 was only common in the late 20th century because Ethernet was common, Ethernet frames have a standard 1500 byte payload capacity (which becomes the IP MTU), and IP and TCP headers were both 20 bytes long in those days. However, around the turn of the 21st century, networks had gotten fast enough that TCP needed to add the 12-byte TCP Timestamp option to protect against wrapped TCP sequence numbers, so typical TCP headers are 32 bytes long now, resulting in a typical 1448 byte TCP MSS on a standard 1500 byte MTU Ethernet network.

Diğer MSS Değerleri

Açıklaması şöyle

On networks with higher path MTUs than 1500 (example: data center networks that use nonstandard 6k or 9k jumbo Ethernet frames), the MSS will be larger. On networks with lower path MTUs than 1500 (example: PPPoE, common on DSL, has 8 additional bytes of overhead for an MTU of 1492), the MSS will be lower.

En Büyük MSS Değeri

Açıklaması şöyle. IP zarfındaki alanını alabileceği en büyük değer 65,535.

The Total Length field in the IP header is 16 bit and thus an IP packet (and therefore TCP packet) can not be larger than 65535 bytes. The TCP payload is actually even smaller since you have to subtract the TCP header from maximum packet size of the IP packet. 

IP zarfındaki bu değer kullanılan TCP zarfına göre biraz daha küçülüp 

65,495 - 40 byte daha küçük

veya

65,483 - 52 byte daha küçük olabiliyor.  Açıklaması şöyle

IPv4's max datagram size (the largest MTU it can fill up) is 2^16 bytes (i.e. 64KiB or 65535 bytes). So the max TCP MSS by today's standards is 65,483 bytes with TCP timestamps on, or 65,495 with them disabled.

ISO 9001

Giriş

Bir çok firma ISO 9001:2000 belgesi alıyor. 

ISO 9001 sadece yapılan işi tarif eden bir süreç olmasını gerektiriyor. İş için kullanılan araçlarla ilgilenmiyor. CMMI ile kıyaslanınca daha yüzeysel.

Bir başka açıklama şöyle

While ISO 9001 and the CMMI for Development provide road maps of good quality practice, the IEEE software and systems engineering standards provide more detailed "how-to" information and guidance.

Modular Multiplicative Inverse

Giriş

Açıklaması şöyle

1. M seçimi : Pick a modulus M, which should be one more than the maximum value the field can hold.

In this case, since the max is 255, we choose M = 256.

2. P seçimi : Pick a number P that’s coprime with M (i.e., they share no common factors except 1).

Let’s go with P = 9.

3. Q seçimi : Now, a number Q such that (P × Q) mod M = 1. Q = 57

Örnek

encoded_value = (original_value * P) % M

original_value = (encoded_value * Q) % M

195 değeri için

219= (195 * 9) % 256

195 = (219 * 57) % 256

aws ce - Cost Expolorer Seçeneği

Örnek

Şöyle yaparız

aws ce get-reservation-utilization

Açıklaması şöyle

In AWS, use Cost Explorer to view your reserved instance utilization and identify opportunities for optimization:

RocksDB - Embedded Database

WAL

Açıklaması şöyle

By default, RocksDB stores all the writes in a WAL along with the memtable. We turned the WAL off given that our use case was self-healing in nature and no data could have been lost.

multiGet

Açıklaması şöyle

RocksDB gives various ways to read data from the DB. You could either fire a get() command or a multiGet() command. multiGet() is more efficient than multiple get() calls in a loop for several reasons such as lesser thread contention on filter/index cache, lesser number of internal method calls, and better parallelization on the IO for different data blocks.

Autocloseable

Açıklaması şöyle

Every class of RocksDB implements an Autocloseable either directly or indirectly. You need to call the close() on RocksDB’s java objects explicitly (or use try-with-resources) whenever you are done using them to release the actual memory held by RocksDB’s C++ objects. Failure to do so can lead to memory leaks.

OAuth2 Token Exchange

Giriş

Açıklaması şöyle

OAuth Token Exchange is specifically designed to exchange one type of token for another, typically for trusted clients to acquire a different kind of token without requiring user involvement. It’s used for various scenarios where a client application needs a specific token to access a resource, such as swapping an access token for a security token or an identity token.

Açıklaması şöyle

In OAuth Token Exchange, user involvement is minimized or absent. The exchange is typically performed by trusted clients or services that have the necessary authorization, and it’s often done without requiring the user to re-authenticate or provide consent.

Şeklen şöyle

Token Issuer

İlk token'ı veren servis

Token Exchange Service

Açıklaması şöyle

The token exchange service validates the request, ensuring that the client is authorized to make the exchange. It may also perform additional checks, such as verifying the original access token’s scope or expiration time.

İlk token doğrulandıktan sonra açıklaması şöyle

Once the request is validated, the token exchange service issues the new token and sends it back to the client. The client can now use the newly acquired token to access the resource or perform the desired action. This token is suitable for the specific resource, and the client doesn’t need to undergo a full authentication and authorization process again.

Örnek

Şöyledir

POST /oauth2/token HTTP/1.1
Host: https://localhost:9443
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <base64-encoded-clientId:clientSecret>

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=http://localhost:8080
&resource=resource-server.com/api/resource
&scope=read write 

Açıklaması şöyle

Here are the key parameters that should be present in a token exchange request

Grant Type

The grant_type parameter specifies the type of token exchange being requested. In the context of Token Exchange, this is usually set to "urn:ietf:params:oauth:grant-type:token-exchange". This indicates the intent to exchange tokens.

Subject Token

The subject_token parameter contains the token that the client application currently holds and wishes to exchange. This token can be an OAuth access token or another type of token.

Subject Token Type

The subject_token_type parameter specifies the type or format of the subject token. Common values include "urn:ietf:params:oauth:token-type:access_token" for OAuth access tokens, but it can vary based on the token being exchanged.

Apart from these, there are a few additional optional parameters

Audience

The audienceparameter specifies the intended audience for the exchanged token. The audience can indicate the resource or service for which the exchanged token will be used.

Resource

The resource parameter is used to specify the target resource server or service where the exchanged token will be presented. It can help ensure that the exchanged token is valid for that resource.

Scope

If scopes are applicable to the token exchange, the scope parameter can be used to define the desired permissions associated with the exchanged token. The scope value may restrict the actions the token can perform.

DO-278A

Giriş

Açıklaması şöyle

DO-278 was updated to DO-278A by the RTCA SC-205 committee and released in December of 2011.

DO-278A sertifikasyonu CNS/ATM (Communication, Navigation, Surveillance, and Air Traffic Management) sistemlerinde kullanılıyor. 

Service History

Açıklaması şöyle

CNS/ATM Systems often have significant non-certified legacy software/hardware that was rolled out before DO-278A took effect. Instead of requiring you to start over and redevelop these systems from scratch, DO-278A allows for the concept of “Service History,” where “history” denotes evidence of strong record-keeping. This allows software engineers to see how the system has functioned in the past and in what capacity so they can ensure the systems are still safe to use and not prone to malfunctions or errors.