RFC 8831

Internet Engineering Task Force (IETF) Request for Comments: 8831 Kategori: Standartlar Yolu ISSN: 2070-1721

R. Jesup Mozilla

S. Loreto Ericsson

M. Tüxen Münster Uygulamalı Bilimler Üniversitesi

Ocak 2021

#Özet

WebRTC çerçevesi, iki eşin web tarayıcıları arasında ses, video ve veri kullanarak doğrudan, etkileşimli ve zengin iletişim için protokol desteğini belirtir. Bu belge, WebRTC çerçevesinin medya dışı veri taşıma yönlerini tanımlar. Web tarayıcılarının eşler arası genel verileri değiş tokuş etmesine olanak tanıyan genel amaçlı bir taşıma hizmeti olarak Akış Denetimli İletim Protokolü’nün (Stream Control Transmission Protocol - SCTP) WebRTC bağlamında nasıl kullanıldığına dair mimari bir genel bakış sunar.

#1. Giriş

WebRTC çerçevesinde, taraflar arasındaki iletişim medya (örneğin ses ve video) ve medya dışı verilerden oluşur. Medya, Secure Real-time Transport Protocol (SRTP) kullanılarak gönderilir ve burada daha ayrıntılı olarak belirtilmez. Medya dışı veriler, DTLS içinde kapsüllenmiş Akış Denetimli İletim Protokolü (SCTP) [RFC4960] kullanılarak ele alınır. DTLS 1.0 [RFC4347]’de tanımlanmıştır; güncel en son sürüm olan DTLS 1.2 [RFC6347]’de tanımlanmıştır; ve yaklaşan bir sürüm olan DTLS 1.3 [TLS-DTLS13]’te tanımlanmıştır.

+----------+
|   SCTP   |
+----------+
|   DTLS   |
+----------+
| ICE/UDP  |
+----------+

Şekil 1: Temel Yığın Diyagramı

ICE/UDP (bkz. [RFC8445]) üzerinde DTLS (bkz. [RFC8261]) üzerinde SCTP’nin kapsüllenmesi, gizlilik, kaynak kimlik doğrulaması ve bütünlüğü korunmuş aktarımlarla birlikte bir NAT geçiş çözümü sağlar. Bu veri taşıma hizmeti, SRTP medya taşıyıcılarına paralel olarak çalışır ve bunların tümü nihayetinde tek bir UDP port numarasını paylaşabilir.

[RFC4960]’da tanımlandığı şekilde SCTP, [RFC3758]’de tanımlanan kısmi güvenilirlik uzantısı (PR-SCTP) ve [RFC7496]’da tanımlanan ek ilkeler ile birlikte, kullanıcı iletileri için güvenilir ve ilgili kısmen güvenilir teslim modlarıyla birlikte yerel olarak birden fazla akış sağlar. [RFC6525]’te tanımlanan yeniden yapılandırma uzantısının kullanılması, bir SCTP birliğinin ömrü boyunca akış sayısının artırılmasına ve bireysel SCTP akışlarının sıfırlanmasına olanak tanır. [RFC8260]’ın kullanılması, tekelleşmeyi önlemek için büyük iletilerin iç içe geçirilmesine izin verir ve SCTP akışlarının önceliklendirilmesi için destek ekler.

Belgenin geri kalanı şu şekilde düzenlenmiştir: Bölüm 3 ve 4, hem güvenilmez hem de güvenilir eşler arası veri kanalları için kullanım senaryolarını ve gereksinimleri sunar; Bölüm 5, UDP üzerinde DTLS üzerinde SCTP’yi ele alır; ve Bölüm 6, web tarayıcıları arasında medya dışı verilerin taşınması için SCTP’nin WebRTC protokol çerçevesi tarafından nasıl kullanılması gerektiğini belirtir.

#2. Kurallar

Bu belgede geçen "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" ve "OPTIONAL" anahtar sözcükleri, yalnızca ve ancak burada gösterildiği gibi tamamen büyük harflerle göründüklerinde, BCP 14 [RFC2119] [RFC8174]’te açıklandığı şekilde yorumlanacaktır.

#3. Kullanım Senaryoları

Bu bölüm, veri kanallarına özgü kullanım senaryolarını tanımlar. Lütfen bu bölümün yalnızca bilgilendirici olduğunu unutmayın.

3.1. Güvenilmez Veri Kanalları için Kullanım Senaryoları

U-C 1: Konum ve nesne durum bilgilerinin bir veya daha fazla güvenilmez veri kanalı üzerinden gönderildiği gerçek zamanlı bir oyun. Herhangi bir zamanda SRTP medya kanalı bulunmayabilir ya da tüm SRTP medya kanalları etkin olmayabilir ve ayrıca kullanımda güvenilir veri kanalları da olabilir.

U-C 2: Bir video sohbeti veya konferansta, sessize alma durumu gibi bir durum güncellemesinin nedenine ilişkin kullanıcıya kritik olmayan bilgilerin sağlanması.

3.2. Güvenilir Veri Kanalları için Kullanım Senaryoları

U-C 3: Kontrol bilgileri gibi kritik durum bilgilerinin aktarılmasının gerektiği gerçek zamanlı bir oyun. Böyle bir oyunda SRTP medya kanalları hiç olmayabilir, herhangi bir zamanda etkin olmayabilir veya yalnızca oyun içi eylemler nedeniyle eklenmiş olabilir.

U-C 4: Sohbet eden kişiler arasında gerçek zamanlı olmayan dosya aktarımları. Bunun, örneğin bir resim klasörünün veya bir dosya dizininin paylaşılması durumunda olduğu gibi, ardışık veya paralel olarak aktarılacak çok sayıda dosyayı içerebileceğini unutmayın.

U-C 5: Bir kişiyle ya da bir konferansta birden fazla kişiyle yapılan sesli ve/veya görüntülü arama sırasında gerçek zamanlı metin sohbeti.

U-C 6: PeerConnection yapılandırmasının yeniden müzakere edilmesi.

U-C 7: Bir tarayıcının, örneğin yerel İnternet filtrelemesini veya izlemeyi önlemek amacıyla, HTTP/HTTPS isteklerini ve verilerini göndermek ve almak için bir PeerConnection’ın veri kanallarını kullandığı vekil tarama.

#4. Gereksinimler

Bu bölüm, iki tarayıcı arasındaki Eşler Arası (P2P) veri kanalları için gereksinimleri listeler. Lütfen bu bölümün yalnızca bilgilendirici olduğunu unutmayın.

Gerek. 1: Birden fazla eşzamanlı veri kanalı desteklenmelidir. Aynı PeerConnection içinde veri kanallarıyla paralel olarak sıfır veya daha fazla SRTP medya akışı bulunabileceğini ve bu SRTP medya akışlarının sayısının ve durumunun (etkin/etkin değil) herhangi bir zamanda değişebileceğini unutmayın.

Gerek. 2: Hem güvenilir hem de güvenilmez veri kanalları desteklenmelidir.

Gerek. 3: Bir PeerConnection’ın veri kanalları, tek tek, bir sınıf olarak ya da PeerConnection’ın SRTP medya akışlarıyla birlikte tıkanıklık denetimine tabi tutulmalıdır. Bu, veri kanallarının bu SRTP medya akışları için tıkanıklık sorunlarına yol açmamasını ve WebRTC PeerConnection’ın TCP bağlantılarıyla paralel çalıştırıldığında aşırı sorunlara neden olmamasını sağlar.

Gerek. 4: Uygulama, her bir veri kanalının birbirlerine ve SRTP medya akışlarına göre göreli önceliği hakkında yönlendirme sağlayabilmelidir. Bu, tıkanıklık denetimi algoritmalarıyla etkileşime girecektir.

Gerek. 5: Veri kanalları güvenli olmalıdır; bu da gizlilik, bütünlük ve kaynak kimlik doğrulamasına olanak tanır. Ayrıntılı bilgi için [RFC8826] ve [RFC8827]’ye bakınız.

Gerek. 6: Veri kanalları, JavaScript uygulamasının gönderilmek üzere ilettiği bir iletinin ne kadar büyük olursa olsun IP katmanı parçalanmasının önlenebilmesi için ileti parçalama desteği sağlamalıdır. Ayrıca, büyük veri kanalı aktarımlarının diğer veri kanallarındaki trafiği gereksiz yere geciktirmemesini de sağlamalıdır.

Gerek. 7: Veri kanalı taşıma protokolü, protokol alanlarının içine yerel IP adreslerini kodlamamalıdır; bunun yapılması potansiyel olarak özel bilgilerin açığa çıkmasına neden olur ve adrese bağımlı olunması durumunda hataya yol açar.

Gerek. 8: Veri kanalı taşıma protokolü, görüntü dosyası aktarımı gibi uygulama katmanındaki kullanım durumları için sınırsız uzunlukta "iletileri" (yani sanal bir soket akışı) desteklemelidir; uygulamalar makul bir ileti boyutu sınırı uygulayabilir.

Gerek. 9: Veri kanalı taşıma protokolü IP parçalanmasından kaçınmalıdır. Yol MTU (PMTU) keşfini desteklemeli ve özellikle PMTU keşfi için ICMP veya ICMPv6’nın oluşturulmasına ya da geri iletilmesine dayanmalıdır.

Gerek. 10: Protokol yığınının kullanıcı uygulama alanında uygulanabilmesi mümkün olmalıdır.

#5. UDP Üzerinde DTLS Üzerinde SCTP ile İlgili Hususlar

WebRTC bağlamında SCTP’nin önemli özellikleri şunlardır:

TCP dostu tıkanıklık denetiminin kullanımı.
SRTP medya akışı tıkanıklık denetimi ile entegrasyon için değiştirilebilir tıkanıklık denetimi.
Her biri sıralı ileti teslimine ilişkin kendi kavramını sağlayan birden fazla tek yönlü akış desteği.
Sıralı ve sırasız ileti teslimi desteği.
Parçalama ve yeniden birleştirme sağlayarak keyfi büyüklükte kullanıcı iletilerinin desteklenmesi.
PMTU keşfi desteği.
Güvenilir veya kısmen güvenilir ileti taşıma desteği.

WebRTC veri kanalı mekanizması SCTP çoklu barındırmayı (multihoming) desteklemez. SCTP katmanı, DTLS katmanının (bağlantı yönelimli, güvenilmez bir datagram hizmeti) sunduğu soyutlama bu olduğu için, tek barındırmalı bir ana bilgisayar üzerinde çalışıyormuş gibi davranacaktır.

[RFC8261]’de tanımlanan DTLS üzerinde SCTP kapsüllemesi, gizlilik, kaynak kimlik doğrulaması ve bütünlüğü korunmuş aktarımlar sağlar. Interactive Connectivity Establishment (ICE) [RFC8445] ile birlikte UDP üzerinde DTLS kullanımı, IPv4 ve IPv6 tabanlı ağlarda ara kutu geçişini mümkün kılar. [RFC4960]’da tanımlandığı şekliyle SCTP, [RFC3758]’de tanımlanan uzantı ile birlikte KULLANILMALIDIR ve tarayıcılar arasında medya dışı verilerin taşınması için aşağıdaki özellikleri sağlar:

Birden fazla tek yönlü akış desteği.
Kullanıcı iletilerinin sıralı ve sırasız teslimi.
Kullanıcı iletilerinin güvenilir ve kısmen güvenilir taşınması.

Her bir SCTP kullanıcı iletisi, gönderici tarafta üst katmanı tarafından SCTP’ye iletilen ve alıcı tarafta üst katmanına sağlanan bir Yük Protokolü Tanımlayıcısı (Payload Protocol Identifier - PPID) içerir. PPID, tek bir SCTP birliği üzerinde birden fazla üst katmanın çoklanması/ayrıştırılması için kullanılabilir. WebRTC bağlamında PPID, UTF-8 kodlu kullanıcı verisi, ikili kodlu kullanıcı verisi ve [RFC8832]’de tanımlanan Veri Kanalı Kurulum Protokolü’nü (Data Channel Establishment Protocol - DCEP) ayırt etmek için kullanılır. PPID’nin JavaScript API üzerinden erişilebilir olmadığını lütfen unutmayın.

DTLS üzerinde SCTP kapsüllemesi, yukarıda listelenen SCTP özellikleriyle birlikte, Bölüm 4’te listelenen tüm gereksinimleri karşılar.

WebRTC için protokollerin katmanlanması Şekil 2’de gösterilmiştir.

+------+------+------+
| DCEP | UTF-8|Binary|
|      | Data | Data |
+------+------+------+
|        SCTP        |
+----------------------------------+
| STUN | SRTP |        DTLS        |
+----------------------------------+
|                ICE               |
+----------------------------------+
| UDP1 | UDP2 | UDP3 | ...         |
+----------------------------------+

Şekil 2: WebRTC Protokol Katmanları

Bu yığın (özellikle DTLS üzerinde SCTP [RFC6083] ile karşılaştırıldığında ve UDP üzerinde SCTP [RFC6951] ile birlikte ele alındığında) aşağıdaki nedenlerle seçilmiştir:

Keyfi büyüklükte kullanıcı iletilerinin iletimini destekler.
PeerConnection’ın SRTP medya kanallarıyla DTLS bağlantısını paylaşır.
SCTP denetim bilgileri için gizlilik sağlar.

Şekil 2’de gösterilen protokol yığınına atıfta bulunarak:

UDP üzerinde DTLS 1.0 kullanımı [RFC4347]’de belirtilmiştir.
UDP üzerinde DTLS 1.2 kullanımı [RFC6347]’de belirtilmiştir.
UDP üzerinde DTLS 1.3 kullanımı, yaklaşan bir belgede [TLS-DTLS13] belirtilmiştir.
DTLS üzerinde SCTP kullanımı [RFC8261]’de belirtilmiştir.

STUN [RFC5389] ile SRTP ve DTLS arasındaki ayrıştırmanın, [RFC5764]’ün 5.1.2 Bölümünde açıklandığı şekilde yapıldığını ve SCTP’nin DTLS’nin tek yükü olduğunu lütfen unutmayın.

DTLS genellikle kullanıcı uygulama alanında uygulandığından, SCTP yığınının da kullanıcı uygulama alanında olması gerekir.

ICE/UDP katmanı, DTLS ve SCTP katmanlarıyla etkileşime gerek duymadan bir oturum sırasında IP adresi değişikliklerini ele alabilir. Ancak, bir adres değişikliği gerçekleştiğinde SCTP BİLDİRİLMELİDİR. Bu durumda SCTP, Yol MTU’yu yeniden test etmeli ve tıkanıklık durumunu başlangıç durumuna sıfırlamalıdır. [RFC4960]’da tanımlanan pencere tabanlı tıkanıklık denetimi gibi durumlarda bu, tıkanıklık penceresinin ve yavaş başlatma eşiğinin başlangıç değerlerine ayarlanması anlamına gelir.

Gelen ICMP veya ICMPv6 iletileri, ilgili birliği tanımlamanın bir yolu olmadığından SCTP katmanı tarafından işlenemez. Bu nedenle SCTP, [RFC4821]’de belirtildiği üzere ICMP veya ICMPv6’ya dayanmadan Yol MTU keşfi gerçekleştirmeyi, [RFC4820]’de belirtilen yoklama iletilerini kullanarak DESTEKLEMELİDİR. IP katmanındaki başlangıç Yol MTU’su IPv4 için 1200 baytı ve IPv6 için 1280 baytı AŞMAMALIDIR.

Genel olarak, bir SCTP uygulamasının alt katman arayüzü, IPv4 ve IPv6 (bağlantısız olmaları) ile DTLS (bağlantı yönelimli olması) arasındaki farklılıkları ele alacak şekilde uyarlanmalıdır.

Şekil 2’de gösterilen protokol yığını kullanıldığında, DTLS tüm SCTP paketini korur; dolayısıyla tüm SCTP paketi için gizlilik, bütünlük ve kaynak kimlik doğrulaması sağlar.

SCTP, birlik başına tıkanıklık denetimi sağlar. Bu, tek bir SCTP birliği içindeki tüm SCTP akışlarının aynı tıkanıklık penceresini paylaştığı anlamına gelir. SCTP üzerinden gönderilmeyen trafik, SCTP tıkanıklık denetimi kapsamında değildir. Standart olandan farklı bir tıkanıklık denetimi kullanılması, paralel SRTP medya akışları üzerindeki etkiyi iyileştirebilir.

SCTP, TCP ve UDP ile aynı port numarası kavramını kullanır. Bu nedenle bir SCTP birliği, her SCTP uç noktasında birer tane olmak üzere iki port numarası kullanır.

#6. Veri Kanalları için SCTP Kullanımı

6.1. SCTP Protokolü ile İlgili Hususlar

[RFC8261]’de açıklandığı şekilde SCTP paketlerinin DTLS kapsüllemesi KULLANILMALIDIR.

Bu SCTP yığını ve onun üst katmanı, birden fazla SCTP akışının kullanımını DESTEKLEMELİDİR. Bir kullanıcı iletisi, sıralı veya sırasız ve kısmi ya da tam güvenilirlik ile gönderilebilir.

Aşağıdaki SCTP protokol uzantıları gereklidir:

[RFC6525]’te tanımlanan akış yeniden yapılandırma uzantısı DESTEKLENMELİDİR. Kanalların kapatılması için kullanılır.
[RFC5061]’de tanımlanan dinamik adres yeniden yapılandırma uzantısı, [RFC6525]’te tanımlanan akış sıfırlama uzantısının desteğini işaretlemek için KULLANILMALIDIR. [RFC5061]’in diğer özellikleri İSTEĞE BAĞLIDIR.
[RFC3758] içinde tanımlanan kısmi güvenilirlik uzantısı desteklenmelidir. [RFC3758] içinde tanımlanan zamanlamalı güvenilirlik PR-SCTP politikasına ek olarak, [RFC7496] içinde tanımlanan sınırlı yeniden iletim politikası da desteklenmelidir. Yeniden iletim sayısının sıfırla sınırlandırılması ve sırasız teslimatın birleştirilmesi, her kullanıcı mesajının tam olarak bir kez gönderildiği ve alındığı sırada teslim edildiği, UDP benzeri bir hizmet sağlar.

[RFC8260] içinde tanımlanan mesaj iç içe geçirme desteğinin kullanılması önerilir.

6.2. SCTP Birliktelik Yönetimi

WebRTC bağlamında, SCTP birlikteliği, WebRTC PeerConnection’ın iki uç noktasının, genellikle Oturum Tanımlama Protokolü (SDP) [RFC8829] alışverişi olan JavaScript Oturum Kurulum Protokolü (JSEP) tarafından müzakere edildiği şekilde açılması üzerinde anlaştıklarında kurulacaktır. ICE aracılığıyla seçilen DTLS bağlantısını kullanacaktır ve tipik olarak bu bağlantı, SRTP ortam akışlarını anahtarlamak için kullanılan DTLS bağlantılarıyla BUNDLE veya eşdeğeri üzerinden paylaşılacaktır.

SCTP birliktelik kurulumu sırasında müzakere edilen akış sayısı 65535 olmalıdır; bu, birliktelik kurulumu sırasında müzakere edilebilecek en yüksek akış sayısıdır.

SCTP, bir SCTP birlikteliğini sonlandırmanın iki yolunu destekler. İlk yöntem, birlikteliğin kapatılması sırasında hiçbir mesajın kaybolmamasını sağlayan bir prosedürün kullanıldığı, zarif bir yöntemdir. İkinci yöntem ise zarif olmayan bir yöntemdir; burada taraflardan biri birlikteliği doğrudan iptal edebilir.

Her SCTP uç noktası, kullanıcı mesajlarının ve test mesajlarının yeniden iletim sayısını izleyerek eşinin erişilebilirliğini sürekli olarak denetler. Aşırı yeniden iletim durumunda, birliktelik zarif olmayan bir şekilde sonlandırılır.

Bir SCTP birlikteliği zarif bir şekilde kapatılırsa, tüm veri kanalları kapatılır. Zarif olmayan bir kapatma durumunda da tüm veri kanalları kapatılır, ancak mümkünse bir hata göstergesi sağlanmalıdır.

6.3. SCTP Akışları

SCTP, bir akışı, başka bir SCTP uç noktasına yönelik olarak bir SCTP birlikteliği içinde var olan tek yönlü mantıksal bir kanal olarak tanımlar. Akışlar, sıralı teslimat kavramını sağlamak ve çoklamalama için kullanılır. Her kullanıcı mesajı, sıralı veya sırasız olarak belirli bir akış üzerinden gönderilir. Sıralama yalnızca aynı akış üzerinde gönderilen sıralı mesajlar için korunur.

6.4. Veri Kanalı Tanımı

Veri kanalları, eşlik eden uygulama düzeyi API’lerinin WebSocket’ler için olan API’yi yakından yansıtabilmesi amacıyla tanımlanmıştır; bu da iki yönlü veri akışlarını ve veri kanalının anlamını tanımlamak için kullanılan "label" adlı metinsel bir alanı ifade eder.

Bir veri kanalının gerçekleştirilmesi, aynı SCTP akış tanımlayıcısına sahip bir gelen akış ve bir giden SCTP akışı çiftidir. Bu SCTP akış tanımlayıcılarının nasıl seçileceği protokole ve uygulamaya bağlıdır. Bu, çift yönlü iletişime olanak tanır.

Buna ek olarak, her veri kanalı her iki yönde aşağıdaki özelliklere sahiptir:

Güvenilir veya güvenilmez mesaj iletimi: Güvenilmez iletimler durumunda, aynı güvenilmezlik düzeyi kullanılır. Bunun SCTP’de bir SCTP kullanıcı mesajının özelliği olduğu ve bir SCTP akışının özelliği olmadığı unutulmamalıdır.
Gönderilen mesajlar için sıralı veya sırasız mesaj teslimi: Bunun da SCTP’de bir SCTP kullanıcı mesajının özelliği olduğu ve bir SCTP akışının özelliği olmadığı unutulmamalıdır.
Bir öncelik, 2 baytlık işaretsiz bir tamsayıdır: Bu öncelikler, [RFC8260] içinde tanımlanan iç içe geçirmeyi destekleyen ilgili akış zamanlayıcısının tanımına göre ağırlıklı-adil-kuyruklama zamanlama öncelikleri olarak yorumlanmalıdır. WebRTC’de kullanım için, kullanılan değerlerin 128 ("normal altı"), 256 ("normal"), 512 ("yüksek") veya 1024 ("çok yüksek") değerlerinden biri olması önerilir.
İsteğe bağlı bir etiket.
İsteğe bağlı bir protokol.

[RFC8832] içinde belirtilen protokol ile müzakere edilen bir veri kanalı için, yukarıdaki özelliklerin tümü her iki yönde de aynıdır.

6.5. Bir Veri Kanalının Açılması

Veri kanalları, SCTP birlikteliği içinde müzakere kullanılarak (bant içi müzakere olarak adlandırılır) veya bant dışı müzakere ile açılabilir. Bant dışı müzakere, bir kanalın parametreleri ve bunun meydana getirilmesi konusunda bir anlaşmayla sonuçlanan herhangi bir yöntem olarak tanımlanır. Ayrıntılar bu belgenin kapsamı dışındadır. Veri kanallarını kullanan uygulamaların, her iki uç noktada da müzakere yöntemlerini tutarlı bir şekilde kullanması gerekir.

Bant içi müzakere için basit bir protokol [RFC8832] içinde belirtilmiştir.

Bir taraf bant dışı müzakere kullanarak bir kanal açmak istediğinde, bir akış seçer. Aksi tanımlanmadıkça veya müzakere edilmedikçe, akışlar DTLS rolüne göre seçilir (istemci çift numaralı akış tanımlayıcılarını, sunucu ise tek numaralı akış tanımlayıcılarını seçer). Ancak, mevcut akışlarla çakışmaların önlenmesinden uygulama sorumludur. Mevcut bir veri kanalının parçası olan bir akışı yeniden kullanmaya çalışırsa, ekleme başarısız olmalıdır. Bir akış seçmeye ek olarak, uygulamanın mesaj göndermek için kullanılacak seçenekleri de belirlemesi önerilir. Uygulama, karşı uçtaki uygulamanın da seçilen akışı ve o taraftan veri göndermek için kullanılacak seçenekleri bileceğini uygulamaya özgü bir şekilde güvence altına almalıdır.

6.6. Bir Veri Kanalı Üzerinden Kullanıcı Verisinin Aktarılması

Her iki yönde bir veri kanalı üzerinden gönderilen tüm veriler, seçenekler değiştirilmedikçe veya daha üst bir düzey tarafından mesaj başına seçenekler belirtilmedikçe, veri kanalının açıldığı sırada tanımlanan güvenilirlik kullanılarak alttaki akış üzerinden gönderilmelidir.

SCTP’nin mesaj yönelimli yapısı, kullanıcı mesajlarının mesaj sınırlarını korumak için kullanılır. Bu nedenle, göndericiler bir SCTP kullanıcı mesajı içine birden fazla uygulama mesajı koymamalıdır. Kullanımdan kaldırılmış PPID tabanlı parçalama ve yeniden birleştirme kullanılmadıkça, gönderici her SCTP kullanıcı mesajına tam olarak bir uygulama mesajı dahil etmelidir.

SCTP Yük Protokol Tanımlayıcıları (PPID’ler), "yük verisinin" nasıl yorumlanacağını belirtmek için kullanılır. Aşağıdaki PPID’ler kullanılmalıdır (Bkz. Bölüm 8):

WebRTC String: UTF-8 olarak kodlanmış boş olmayan bir JavaScript dizesini tanımlamak için.
WebRTC String Empty: UTF-8 olarak kodlanmış boş bir JavaScript dizesini tanımlamak için.
WebRTC Binary: boş olmayan JavaScript ikili verisini (ArrayBuffer, ArrayBufferView veya Blob) tanımlamak için.
WebRTC Binary Empty: boş JavaScript ikili verisini (ArrayBuffer, ArrayBufferView veya Blob) tanımlamak için.

SCTP, boş kullanıcı mesajlarının gönderilmesini desteklemez. Bu nedenle, boş bir mesaj gönderilmesi gerekiyorsa, uygun PPID (WebRTC String Empty veya WebRTC Binary Empty) kullanılır ve bir sıfır baytlık SCTP kullanıcı mesajı gönderilir. Bu PPID’lerden biriyle bir SCTP kullanıcı mesajı alındığında, alıcı SCTP kullanıcı mesajını yok saymalı ve bunu boş bir mesaj olarak işlemelidir.

"WebRTC String Partial" ve "WebRTC Binary Partial" PPID’lerinin kullanımı kullanımdan kaldırılmıştır. Bunlar, güvenilir ve sıralı veri kanallarına ait kullanıcı mesajlarının PPID tabanlı parçalanması ve yeniden birleştirilmesi için kullanılmıştır.

Desteklenmeyen bir PPID içeren bir mesaj alınırsa veya alıcı tarafından alınan mesajla ilgili herhangi bir hata durumu tespit edilirse (örneğin, geçersiz sıralama), alıcı ilgili veri kanalını kapatmalıdır. Bu özellikle, ek PPID’ler kullanan uzantıların önceden müzakere edilmeden kullanılamayacağı anlamına gelir.

[RFC4960] içinde belirtilen SCTP temel protokolü, kullanıcı mesajlarının iç içe geçirilmesini desteklemez. Bu nedenle, büyük bir kullanıcı mesajının gönderilmesi SCTP birlikteliğini tekeline alabilir. Bu sınırlamayı aşmak için, [RFC8260] mesaj iç içe geçirmeyi destekleyen bir uzantı tanımlar ve bunun kullanılması önerilir. Mesaj iç içe geçirme desteklenmediği sürece, tekelleşmeyi önlemek için göndericinin azami mesaj boyutunu 16 KB ile sınırlaması önerilir.

Uygulamaların keyfi olarak büyük tekil mesajları destekleyemeyeceği göz önüne alındığında, mesaj boyutunun belirli sınırlar içinde tutulması tavsiye edilir. Bu sınır, örneğin [RFC8841] kullanılarak müzakere edilmelidir.

Gecikmeyi en aza indirmek için göndericinin Nagle algoritmasını (Bkz. [RFC1122]) devre dışı bırakması önerilir.

6.7. Bir Veri Kanalının Kapatılması

Bir veri kanalının kapatılması, ilgili giden akışların sıfırlanmasıyla [RFC6525] bildirilmelidir. Bu, bir taraf veri kanalını kapatmaya karar verirse, ilgili giden akışı sıfırladığı anlamına gelir. Karşı taraf, bir gelen akışın sıfırlandığını gördüğünde, kendi ilgili giden akışını da sıfırlar. Bu işlem tamamlandığında, veri kanalı kapatılmış olur. Bir akışın sıfırlanması, akışın Akış Sıra Numaralarını (SSN’ler) sıfıra geri ayarlar ve sıfırlamanın gerçekleştirildiğine dair uygulama katmanına karşılık gelen bir bildirim sağlar. Sıfırlama gerçekleştirildikten sonra akışlar yeniden kullanım için uygundur.

[RFC6525], ayrıca, akış sıfırlanmadan önce tüm mesajların teslim edildiğini (veya terk edildiğini) garanti eder.

#7. Güvenlik Hususları

Bu belge, [RFC8826] ve [RFC8827] içinde verilenlere ek herhangi bir husus eklemez.

Bir alıcının, keyfi olarak büyük mesajlar göndermeye çalışan bir göndericiye karşı hazırlıklı olması gerektiği belirtilmelidir.

#8. IANA Hususları

Bu belge, halihazırda kayıtlı altı adet SCTP Yük Protokol Tanımlayıcısını (PPID) kullanır: "DOMString Last", "Binary Data Partial", "Binary Data Last", "DOMString Partial", "WebRTC String Empty" ve "WebRTC Binary Empty". [RFC4960], bu tanımlayıcıların atandığı "SCTP Payload Protocol Identifiers" kayıt defterini oluşturur. IANA, bu altı atamanın referansını bu belgeyi gösterecek şekilde güncellemiş ve ilk dört PPID’nin adlarını değiştirmiştir. Karşılık gelen tarihler değişmeden kalmıştır.

Altı atama aşağıdaki şekilde güncellenmiştir:

| Değer | SCTP PPID | Referans | Tarih | |---------------------|-----------|----------|------------| | WebRTC String | 51 | RFC 8831 | 2013-09-20 | | WebRTC Binary | 52 | RFC 8831 | 2013-09-20 | | Partial (kullanımdan kaldırıldı)| | | | | WebRTC Binary | 53 | RFC 8831 | 2013-09-20 | | WebRTC String | 54 | RFC 8831 | 2013-09-20 | | Partial (kullanımdan kaldırıldı)| | | | | WebRTC String Empty | 56 | RFC 8831 | 2014-08-22 | | WebRTC Binary Empty | 57 | RFC 8831 | 2014-08-22 |

Tablo 1

#9. Kaynaklar

9.1. Normatif Kaynaklar

[RFC2119] Bradner, S., "RFC’lerde Gereksinim Düzeylerini Belirtmek için Kullanılan Anahtar Sözcükler", BCP 14, RFC 2119, DOI 10.17487/RFC2119, Mart 1997, https://www.rfc-editor.org/info/rfc2119.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M. ve P. Conrad, "Akış Denetimli İletim Protokolü (SCTP) Kısmi Güvenilirlik Uzantısı", RFC 3758, DOI 10.17487/RFC3758, Mayıs 2004, https://www.rfc-editor.org/info/rfc3758.
[RFC4820] Tuexen, M., Stewart, R. ve P. Lei, "Akış Denetimli İletim Protokolü (SCTP) için Dolgu Parçası ve Parametresi", RFC 4820, DOI 10.17487/RFC4820, Mart 2007, https://www.rfc-editor.org/info/rfc4820.
[RFC4821] Mathis, M. ve J. Heffner, "Paketleme Katmanı Yol MTU Keşfi", RFC 4821, DOI 10.17487/RFC4821, Mart 2007, https://www.rfc-editor.org/info/rfc4821.
[RFC4960] Stewart, R., Ed., "Akış Denetimli İletim Protokolü", RFC 4960, DOI 10.17487/RFC4960, Eylül 2007, https://www.rfc-editor.org/info/rfc4960.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S. ve M. Kozuka, "Akış Denetimli İletim Protokolü (SCTP) Dinamik Adres Yeniden Yapılandırması", RFC 5061, DOI 10.17487/RFC5061, Eylül 2007, https://www.rfc-editor.org/info/rfc5061.

#Kaynaklar

[RFC6525] Stewart, R., Tuexen, M. ve P. Lei, "Akış Denetimli İletim Protokolü (SCTP) Akış Yeniden Yapılandırması", RFC 6525, DOI 10.17487/RFC6525, Şubat 2012, https://www.rfc-editor.org/info/rfc6525.
[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R. ve S. Loreto, "Kısmen Güvenilir Akış Denetimli İletim Protokolü Uzantısı için Ek Politikalar", RFC 7496, DOI 10.17487/RFC7496, Nisan 2015, https://www.rfc-editor.org/info/rfc7496.
[RFC8174] Leiba, B., "RFC 2119 Anahtar Sözcüklerinde Büyük Harf ve Küçük Harf Belirsizliği", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Mayıs 2017, https://www.rfc-editor.org/info/rfc8174.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S. ve R. Seggelmann, "Akış Denetimli İletim Protokolü için Akış Zamanlayıcıları ve Kullanıcı Mesajı İç İçe Geçirme", RFC 8260, DOI 10.17487/RFC8260, Kasım 2017, https://www.rfc-editor.org/info/rfc8260.
[RFC8261] Tuexen, M., Stewart, R., Jesup, R. ve S. Loreto, "SCTP Paketlerinin Datagram Taşıma Katmanı Güvenliği (DTLS) ile Kapsüllenmesi", RFC 8261, DOI 10.17487/RFC8261, Kasım 2017, https://www.rfc-editor.org/info/rfc8261.
[RFC8445] Keranen, A., Holmberg, C. ve J. Rosenberg, "Etkileşimli Bağlantı Kurma (ICE): Ağ Adresi Çeviricisi (NAT) Geçişi için Bir Protokol", RFC 8445, DOI 10.17487/RFC8445, Temmuz 2018, https://www.rfc-editor.org/info/rfc8445.
[RFC8826] Rescorla, E., "WebRTC için Güvenlik Hususları", RFC 8826, DOI 10.17487/RFC8826, Ocak 2021, https://www.rfc-editor.org/info/rfc8826.
[RFC8827] Rescorla, E., "WebRTC Güvenlik Mimarisi", RFC 8827, DOI 10.17487/RFC8827, Ocak 2021, https://www.rfc-editor.org/info/rfc8827.
[RFC8829] Uberti, J., Jennings, C. ve E. Rescorla, Ed., "JavaScript Oturum Kurulum Protokolü (JSEP)", RFC 8829, DOI 10.17487/RFC8829, Ocak 2021, https://www.rfc-editor.org/info/rfc8829.
[RFC8832] Jesup, R., Loreto, S. ve M. Tüxen, "WebRTC Veri Kanalı Kurulum Protokolü", RFC 8832, DOI 10.17487/RFC8832, Ocak 2021, https://www.rfc-editor.org/info/rfc8832.
[RFC8841] Holmberg, C., Shpount, R., Loreto, S. ve G. Camarillo, "Datagram Taşıma Katmanı Güvenliği (DTLS) Taşıması Üzerinden Akış Denetimli İletim Protokolü (SCTP) için Oturum Tanımlama Protokolü (SDP) Teklif/Cevap Prosedürleri", RFC 8841, DOI 10.17487/RFC8841, Ocak 2021, https://www.rfc-editor.org/info/rfc8841.

9.2. Bilgilendirici Kaynaklar

[RFC1122] Braden, R., Ed., "İnternet Ana Bilgisayarları için Gereksinimler - İletişim Katmanları", STD 3, RFC 1122, DOI 10.17487/RFC1122, Ekim 1989, https://www.rfc-editor.org/info/rfc1122.
[RFC4347] Rescorla, E. ve N. Modadugu, "Datagram Taşıma Katmanı Güvenliği", RFC 4347, DOI 10.17487/RFC4347, Nisan 2006, https://www.rfc-editor.org/info/rfc4347.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P. ve D. Wing, "NAT için Oturum Geçiş Yardımcıları (STUN)", RFC 5389, DOI 10.17487/RFC5389, Ekim 2008, https://www.rfc-editor.org/info/rfc5389.
[RFC5764] McGrew, D. ve E. Rescorla, "Güvenli Gerçek Zamanlı Taşıma Protokolü (SRTP) için Anahtarların Kurulmasına Yönelik Datagram Taşıma Katmanı Güvenliği (DTLS) Uzantısı", RFC 5764, DOI 10.17487/RFC5764, Mayıs 2010, https://www.rfc-editor.org/info/rfc5764.
[RFC6083] Tuexen, M., Seggelmann, R. ve E. Rescorla, "Stream Control Transmission Protocol (SCTP) için Datagram Transport Layer Security (DTLS)", RFC 6083, DOI 10.17487/RFC6083, Ocak 2011, https://www.rfc-editor.org/info/rfc6083.
[RFC6347] Rescorla, E. ve N. Modadugu, "Datagram Transport Layer Security Sürüm 1.2", RFC 6347, DOI 10.17487/RFC6347, Ocak 2012, https://www.rfc-editor.org/info/rfc6347.
[RFC6951] Tuexen, M. ve R. Stewart, "Uç Ana Bilgisayardan Uç Ana Bilgisayara İletişim için Stream Control Transmission Protocol (SCTP) Paketlerinin UDP Kapsüllenmesi", RFC 6951, DOI 10.17487/RFC6951, Mayıs 2013, https://www.rfc-editor.org/info/rfc6951.
[TLS-DTLS13] Rescorla, E., Tschofenig, H. ve N. Modadugu, "Datagram Transport Layer Security (DTLS) Protokolü Sürüm 1.3", Devam Eden Çalışma, Internet-Draft, draft-ietf-tls-dtls13-39, 2 Kasım 2020, https://tools.ietf.org/html/draft-ietf-tls-dtls13-39.