udp傳輸加密

⑴ TCP/TLS/UDP 有什麼區別

TCP和UDP都是網路層上的協議，是建立在IP層之上的。
TCP是有連接的傳輸，它通過對它下層IP包的沖突、錯誤檢測和重傳，保證了最終接收到的數據是可靠的；UDP是無連接的，數據包發出去就不管了，沒有數據包是否成功並且正確發送的檢查，不能保證數據傳輸100%正確，但是開銷會比較小。

TLS是在更上一層的協議，他必須建立在可靠的數據傳輸基礎上，所以一般是在TCP之上，當然也可以建立在SCTP之上，但是一定不是UDP之上。TLS全名叫傳輸層安全（Transpot Layer Security）協議，TLS連接的建立有個標準的握手過程，可以查看RFC2246了解具體的細節。簡單的講，就是通信雙方互相驗證對方的數字證書，確認對方的身份，並通過密鑰交換協議，確定出相互通信時使用的加密演算法和密鑰，之後的數據通信都使用協商好的加密演算法進行加密傳輸。
它可以保證：1. 與自己通信的一方確實是他自己聲明的身份（通過證書檢查確認）。 2. 通信時的數據傳輸的安全的（因為加密過了，中間即使被竊聽，也沒法解密，沒法知道具體的內容）。

⑵ UDP協議和TCP/IP協議有哪些區別

記得好像udp傳輸協議對傳輸數據不進行加密和數據完整性驗證，tcp/ip則要對數據進行包裝，並認證數據完整性。

⑶ 關於udp協議區域網

ip是第三層協議，udp是第四層，就是在ip之上。如果不能收到ip（路由器沒有轉發），則無法收到udp。標准路由器不具備監聽功能，它只負責分析ip，並將其轉發到應該去的埠。具備安全策略的路由器會分析第四層，但也僅限於對udp埠的解析（阻止或允許通過），離qq（應用層）還很遙遠。所謂竊聽，通常需要專用旁路設備，就是將所有到達路由器的信息鏡像到這個特殊設備所在埠才行，如入侵檢測設備；也可以在路由器中增加監聽功能，如入侵防禦設備。當然，廠家也很容易在路由設備中預留監聽後門，所以一般要害部門不會使用他國的路由設備，或者乾脆物理隔絕。

⑷ TCP與UDP之間有什麼相同點和不同點

相同點：
1、OSI網路層
它們都根據OSI參考模型生活在同一層。我們稱這層為傳輸層。在套接字之間的這一層中，傳
輸數據。他們在這方面沒有區別。
2、安全
從安全形度來看，TCP和UDP都是相同的。實際上，TCP由於其會話管理而具有一些小優勢，
但從總體上看，如果實現SSL，加密等安全機制，則存在安全性。除UDP之外，實現類似TCP
的協議的SSL
/
TLS非常容易。另一方面，像RTP這樣的語音通信協議可以升級到SRTP，使底
層UDP更安全。

不同點：
1、數據包結構
UDP具有精簡包結構。UDP在其標題部分中僅提供源，目標埠，長度，校驗和。TCP在包中
有更多欄位，因為TCP傳輸有更多的步驟和控制項來進行包傳遞。TCP有12個頭欄位。
2、復雜程度
TCP絕對比UDP協議更復雜。正如我們在上側看到的，TCP具有很多傳輸相關機制的區域。例
如，TCP提供了設置傳輸緩沖區相關內存的窗口機制。UDP只有校驗和機制和數據包計數器，
有時候沒有實現。
3、演算法
要使用TCP傳輸數據，必須使用名為3次握手的方法創建會話。第一個客戶端發送一個包含SYN
標志的數據包，伺服器用ACK標志響應，最後一步客戶端發送SYNC
+
ACK以完成與相關服務
器的TCP會話。UDP沒有任何特殊演算法。UDP包直接發送到伺服器的埠。管理層通常在上層
應用程序層中執行。
4、速度
TCP協議的復雜性使TCP比UDP慢。至少要發送一個位元組，需要進行會話初始化，並在數據傳
輸後關閉會話。這使TCP變慢。關於TCP的速度已經做了一些工作，但架構是有限的新增強功
能。如果您通過光纖傳輸UDP，則UDP 速度很快.UDP速度很快，因為沒有會話或會話終止的
演算法。
5、可靠性
TCP是一種可靠的協議，因為它運行機制來防止數據丟失或更改。TCP使用會話來提高數據傳
輸的可靠性。同樣在數據傳輸中，在兩側之間檢查傳輸的數據，並且如果發生一些丟失或改
變，則再次重新傳輸數據。UDP也不可靠。真的不是。但是，如果您希望它是可靠的上層應用
程序級別機制可以實現，但這些將使傳輸更復雜。
6、協議
在這部分中，列出使用UDP或TCP或兩者的協議。
UDP以下協議使用UDP傳輸。
DHCP
DNS
流
RDP
TFTP
SNMP
VOIP
TCP以下協議使用TCP傳輸。
HTTP
HTTPS
FTP
SMTP
TELNET

⑸ udp如何保證數據傳輸的可靠性

UDP要達到TCP的功能就必須實現擁塞控制的功能,而且是在路由之間實現,這個在底層明顯是做不到擁塞控制的,在應用層也是做不到的,因為應用層之間和應用程序掛鉤,一般只能操控主機的程序,而表示層是處理所有與數據表示及運輸有關的問題，包括轉換、加密和壓縮,在傳輸層是不可能的,因為你已經使用了UDP協議,無法在本層轉換它,所以只有在會話層

⑹ UDP傳送數據時，會對數據進行加密嗎

不會。
udp的特點就是不加密啊

⑺ UDP與TCP區別

從專業的角度說，TCP的可靠保證，是它的三次握手機制，這一機制保證校驗了數據，保證了他的可靠性。而UDP就沒有了，所以不可靠。不過UDP的速度是TCP比不了的，而且UDP的反應速度更快，QQ就是用UDP協議傳輸的，HTTP是用TCP協議傳輸的，不用我說什麼，自己體驗一下就能發現區別了。再有就是UDP和TCP的目的埠不一樣（這句話好象是多餘的），而且兩個協議不在同一層，TCP在三層，UDP不是在四層就是七層。

⑻ 如何讓UDP實現可靠傳輸

如何讓UDP實現可靠傳輸
自定義通訊協議，在應用層定義一些可靠的協議，比如檢測包的順序，重復包等問題，如果沒有收到對方的ACK，重新發包
UDP沒有Delievery Garuantee，也沒有順序保證，所以如果你要求你的數據發送與接受既要高效，又要保證有序，收包確認等，你就需要在UDP協議上構建自己的協議。比如RTCP，RTP協議就是在UPD協議之上專門為H.323協議簇上的IP電話設計的一種介於傳輸層和應用層之間的協議。
下面分別介紹三種使用UDP進行可靠數據傳輸的協議
RUDP
RTP
UDT
RUDP（Reliable User Datagram Protocol）
可靠用戶數據報協議（RUDP）是一種基於可靠數據協議（RDP： RFC908 和 1151 （第二版））的簡單分組傳輸協議。作為一個可靠傳輸協議，RUDP 用於傳輸 IP 網路間的電話信號。它允許獨立配置每個連接屬性，這樣在不同的平台可以同時實施不同傳輸需求下的協議。
RUDP 提供一組數據服務質量增強機制，如擁塞控制的改進、重發機制及淡化伺服器演算法等，從而在包丟失和網路擁塞的情況下， RTP 客戶機（實時位置）面前呈現的就是一個高質量的 RTP 流。在不幹擾協議的實時特性的同時，可靠 UDP 的擁塞控制機制允許 TCP 方式下的流控制行為。
為了與網路 TCP 通信量同時工作，
RUDP 使用類似於 TCP 的重發機制和擁塞控制演算法。
在最大化利用可用帶寬上，這些演算法都得到了很好的證明。
RUDP特性
客戶機確認響應伺服器發送給客戶機的包；
視窗和擁塞控制，伺服器不能超出當前允許帶寬；
一旦發生包丟失，伺服器重發給客戶機；
比實時流更快速，稱為「緩存溢出」。
用戶數據報協議（UDP）
RTP（Real Time Protocol）
RTP，實時協議被用來為應用程序如音頻，視頻等的實時數據的傳輸提供端到端（end to end）的網路傳輸功能。傳輸的模型可以是單點傳送或是多點傳送。數據傳輸被一個姐妹協議——實時控制協議（RTCP）來監控，後者允許在一個大的多點傳送網路上監視數據傳送，並且提供最小限度的控制和識別功能。
RTP是被IETF在RFC1889中提出來的。順帶提及，RTP已經被接受為實時多媒體傳送的通用標准。ITU-T跟IETF都在各自的系統中將這一協議標准化。
1.1 為何需要RTP?
TCP不能支持像交互視頻，會議等的實時服務，這一原因是由於TCP只是一個「慢」協議，需要三次握手。就此在IP層上UDP是一個比TCP更好的選擇。但是UDP是本質上是一個不可靠協議，不支持在包丟情況下的重傳機制。誠然，UDP有一些特性，比如多路復用跟校驗和服務，這些都是對實時服務很有利的。為了消除UDP的缺點，RTP是作為應用層而被提出來的。
RTP提供的各種服務包括有效負載識別，序列編號，時間戳和投遞監聽。RTP能夠序列化包，當這些包在收端不是按順序到達的時。序列號也能被用來識別包丟失。時間戳被用於媒體有效的播放。到達的數據一直被RTCP監聽，以通知RTP層來校正其編碼和傳輸的參數。例如，如果RTCP層檢測到包丟失，它會通知RTP層減緩發送速率。
盡管RTP有助於實時媒體的有效的播放，但是要注意的是RTP自身並不提供任何機制來確保及時傳遞或提供其他服務質量（QoS）的保證，而是依靠低層服務來完成這些。同樣，RTP也不保證投遞或防止無序投遞。RTP被設計出來主要是為了滿足有多個參加者的多媒體會議的需要。RTP也同樣適合於象持續數據的儲存，分布式交互模擬，主動標記以及應用程序的控制和測量。
1.2 RTP特性一覽
RTP提供有效負荷類型識別，亂序重排和利用時間戳的媒體有效播放。
RTCP監控服務質量，也提供在一個當前進行的會話中傳送關於參加者的信息作用。
RTP對於下層協議是獨立的，它能夠工作在像TCP/IP，ATM，幀時延等類型的網路上。
如果被下層網路支持，RTP支持利用多路技術的對於多點的數據傳輸。
RTP序列號也能被用來確定包的合適位置。例如在視頻解碼，包無需按序解碼。
2.0 技術概覽
2.1 RTP
RTP頭具有如下的格式。開始的12個八位位元組在每一個RTP包中都會出現；而CSRC標識符列表只在通過混合器的包中出現.
Version (V) （版本號）:這個域長度為2比特，標出了RTP的最近版本。當前的版本為2.0
Padding (P) （填充）:這個域長度為1比特，如果P被置位，包在結尾處包含有一個或多個附加的填充位元組，這些填充位元組不是有效負荷的一部分。填充是一些需要固定塊大小的加密演算法所要求的，或是為了在低層PDU搬運RTP包。
Extension (X):這個域長度為1比特，如果被置位，固定的頭後面緊跟了一個頭的擴展。
CSRC count (CC):這個域長度為4比特。這個域表示了跟在固定頭後面的CSRC標識符的數目。如前所述，這個域只有在通過一個混合器才有非零值。
Marker bit (M): 這個域長度為1比特，如果M被置位，表示一些重要的項目如幀邊界在包中被標記。例如，如果包中有幾個比特的當前幀，連同前一幀，那麼RTP的這一位就被置位。
Payload type (PT) （有效負荷類型）:這個域長度為7比特，PT指示的是有RTP包中的有效負荷的類型。RTP音頻視頻簡介(AVP)包含了一個默認的有效負荷類型碼到有效負荷格式的映射。附加的有效負荷類型可以向IANA注冊。
Sequence number（序列號）：這個域長度為16個比特，每送一個RTP包數目就增加一，初始值被設為一個隨機數。接收方不僅可以用這個序列號檢測包丟失，也可以重組包序列。
Time stamp（時間戳）:這個域長度為32個比特，時間戳反映了RTP數據包的頭一個位元組的采樣時刻。采樣時刻必須是由一個單調線性增加的時鍾產生，這樣做是為了接收方的同步和抖動計算。初始值必須為隨機數，這是為了避免對原碼的攻擊。例如，如果RTP源使用了一個編碼器，緩沖20ms的音頻數據，那麼RTP時間戳必須每個包增加160，無論包是被傳遞了還是被丟失了。
SSRC:這個域長度為32比特，這個域表示了正在為會話產生RTP包的源。這個標識符是隨機選中的，目的是為了避免同一個RTP會話中兩個源有相同的標識符。
CSRC list: 這個列表標識了在這個包中對有效負荷起作用的所有源。標識符的最大數目限定為15，這是由CC域所限定的（全零在CC域中是被禁止的）。如果有超過15個的分配源，只有前15個被標識。
仔細觀察RTP可以注意到它不像更低層的協議比如PDU一樣，包含一個「定邊界」的域。這一原因是RTP的有效負荷是跟IP的有效負荷相同，因此也就不需要了。
如果相同的用戶在一個會話中使用多個媒體，比如說視頻跟音頻，每個媒體都會打開單獨的RTP會話。因此在RTP層面上不存在多路復用。多路復用由更低層來決定。但是RTCP保留了一個叫CNAME的標識符，這個標識符對於由同一用戶初始化的媒體是相同的。因此CNAME是在RTP層面上能識別從一個用戶產生的不同媒體的唯一的標識符。
UDT（UDP-based Data Transfer Protocol）
基於UDP的數據傳輸協議（UDP-based Data Transfer Protocol，簡稱UDT）是一種互聯網數據傳輸協議。UDT的主要目的是支持高速廣域網上的海量數據傳輸，而互聯網上的標准數據傳輸協議TCP在高帶寬長距離網路上性能很差。 顧名思義，UDT建於UDP之上，並引入新的擁塞控制和數據可靠性控制機制。UDT是面向連接的雙向的應用層協議。它同時支持可靠的數據流傳輸和部分可靠的數據報傳輸。 由於UDT完全在UDP上實現，它也可以應用在除了高速數據傳輸之外的其它應用領域，例如點到點技術（P2P），防火牆穿透，多媒體數據傳輸等等。
UDT是雙工的，每個UDT實體有兩個部分：發送和接收。發送者根據流量控制和速率控制來發送（和重傳）應用程式數據。接收者接收數據包和控制包，並根據接收到的包發送控制包。發送和接收程式共享同一個UDP埠來發送和接收。
接收者也負責觸發和處理任何的控制事件，包括擁塞控制和可靠性控制和他們的相對機制，例如RTT估計、帶寬估計、應答和重傳。
UDT總是試著將應用層數據打包成固定的大小，除非數據不夠這么大。和TCP相似的是，這個固定的包大小叫做MSS（最大包大小）。由於期望UDT用來傳輸大塊數據流，我們假定只有很小的一部分不規則的大小的包在UDT session中。MSS能夠通過應用程式來安裝，MTU是其最優值（包括任何包頭）。
UDT擁塞控制演算法將速率控制和窗口（流量控制）合並起來，前者調整包的發送周期，後者限制最大的位被應答的包。在速率控制中使用的參數通過帶寬估計技術來更新，他繼承來自基於接收的包方法。同時，速率控制周期是估計RTT的常量，流控制參數依賴於對方的數據到達速度，另外接收端釋放的緩沖區的大小。
UDP構建可靠數據傳輸
簡單來講，要使用UDP來構建可靠的面向連接的數據傳輸，就要實現類似於TCP協議的超時重傳，有序接受，應答確認，滑動窗口流量控制等機制，等於說要在傳輸層的上一層（或者直接在應用層）實現TCP協議的可靠數據傳輸機制，比如使用UDP數據包+序列號，UDP數據包+時間戳等方法，在伺服器端進行應答確認機制，這樣就會保證不可靠的UDP協議進行可靠的數據傳輸，不過這好像也是一個難題！

⑼ 如何在voip中使用rc4對udp收發函數進行加密

qutecom 一個開源的voip客戶端
asterisk 開源的ippbx
rc4加密演算法簡單，快速，據說是比DES演算法快10倍。sip 信令本身就屬於明文方式傳輸的，之所以要加密，是為了防止運營商的干擾，使用一個弱的加密演算法，是要能防止串改就滿足要求了。
rc4 演算法可以google原來，用密鑰來生成一個256長度的box， 然後box與明文異或操作得到密文，密文再次異或就恢復明文。
下面實現了 qutecom 到asterisk 信令的當向加密，反向的目前還沒弄完，等完工了在來補充。

rc4.h
/*
*RC4 functions for HTMLDOC.
*
* Original code by Rob Earhart
* Copyright 1999 by Carnegie Mellon University, All Rights Reserved
*
* Permission to use, , modify, and distribute this software and its
* documentation for any purpose and without fee is hereby granted,
* provided that the above right notice appear in all copies and that
* both that right notice and this permission notice appear in
* supporting documentation, and that the name of Carnegie Mellon
* University not be used in advertising or publicity pertaining to
* distribution of the software without specific, written prior
* permission.
*
* CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO
* THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE FOR
* ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
* OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/

#ifndef _RC4_H_
# define _RC4_H_

# ifdef __cplusplus
extern "C" {
# endif /* __cplusplus */

/*
* RC4 context...
*/

typedef struct
{
unsigned char sbox[256]; /* S boxes for encryption */
int i, j; /* Current indices into S boxes */
} rc4_context_t;

/*
* Prototypes...
*/

extern void rc4_init(rc4_context_t *context, const unsigned char *key,
unsigned keylen);
extern void rc4_encrypt(rc4_context_t *context, const unsigned char *input,
unsigned char *output, unsigned len);

# ifdef __cplusplus
}
# endif /* __cplusplus */

#endif /* !_RC4_H_ */

rc4.c
/*
* RC4 functions for HTMLDOC.
*
* Original code by Tim Martin
* Copyright 1999 by Carnegie Mellon University, All Rights Reserved
*
* Permission to use, , modify, and distribute this software and its
* documentation for any purpose and without fee is hereby granted,
* provided that the above right notice appear in all copies and that
* both that right notice and this permission notice appear in
* supporting documentation, and that the name of Carnegie Mellon
* University not be used in advertising or publicity pertaining to
* distribution of the software without specific, written prior
* permission.
*
* CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO
* THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE FOR
* ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
* OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*
* Contents:
*
* rc4_init() - Initialize an RC4 context with the specified key.
* rc4_encrypt() - Encrypt the given buffer.
*/

#include "rc4.h"

/*
* 'rc4_init()' - Initialize an RC4 context with the specified key.
*/

void
rc4_init(rc4_context_t *text, /* IO - Context */
const unsigned char *key, /* I - Key */
unsigned keylen) /* I - Length of key */
{
int i, j; /* Looping vars */
unsigned char tmp; /* Temporary variable */

/*
* Fill in linearly s0=0, s1=1, ...
*/

for (i = 0; i < 256; i ++)
text->sbox[i] = i;

for (i = 0, j = 0; i < 256; i ++)
{
/*
* j = (j + Si + Ki) mod 256
*/

j = (j + text->sbox[i] + key[i % keylen]) & 255;

/*
* Swap Si and Sj...
*/

tmp = text->sbox[i];
text->sbox[i] = text->sbox[j];
text->sbox[j] = tmp;
}

/*
* Initialized counters to 0 and return...
*/

text->i = 0;
text->j = 0;
}

/*
* 'rc4_encrypt()' - Encrypt the given buffer.
*/

void
rc4_encrypt(rc4_context_t *text, /* I - Context */
const unsigned char *input, /* I - Input buffer */
unsigned char *output, /* O - Output buffer */
unsigned len) /* I - Size of buffers */
{
unsigned char tmp; /* Swap variable */
int i, j; /* Looping vars */
int t; /* Current S box */

/*
* Loop through the entire buffer...
*/

i = text->i;
j = text->j;

while (len > 0)
{
/*
* Get the next S box indices...
*/

i = (i + 1) & 255;
j = (j + text->sbox[i]) & 255;

/*
* Swap Si and Sj...
*/

tmp = text->sbox[i];
text->sbox[i] = text->sbox[j];
text->sbox[j] = tmp;

/*
* Get the S box index for this byte...
*/

t = (text->sbox[i] + text->sbox[j]) & 255;

/*
* Encrypt using the S box...
*/

*output++ = *input++ ^ text->sbox[t];
len --;
}

/*
* Copy current S box indices back to context...
*/

text->i = i;
text->j = j;
}

修改exosip項目中的 jcallback.c 在函數cb_udp_snd_message 中修改，加入rc4加密部分
....

if( 1 )
{
rc4_context_t context;
char * key = "*****";
unsigned char * out = NULL;
int i=0;
out = osip_malloc (length);
if (out == NULL)
return -1;
rc4_init(&context,key,16);
rc4_encrypt(&context,message,out,length);

rc4_message = osip_malloc(length+4);
if(rc4_message != NULL)
{
rc4_message[0] = 'R';
rc4_message[1] = 'C';
rc4_message[2] = '4';
rc4_message[3] = ':';
for(i=0;i<length;i++)
{
rc4_message[i+4] = out[i];
}
}
osip_free(out);
}

// Really send the packet over network
if(rc4_message == NULL)
{
i = owsip_send (account, (const void*) message, length, 0, address, OWSL_ADDRESS_SIZE);
}
else
{
i = owsip_send (account, (const void*) rc4_message, length+4, 0, address, OWSL_ADDRESS_SIZE);
osip_free(rc4_message);
}
....

在asterisk 中的chan_sip.c 修改函數 sipsock_read， 添加 接受信令rc4解密代碼
.....
if(res>4 && req.data[0]=='R' && req.data[1]=='C' && req.data[2]=='4' && req.data[3]==':')
{
rc4_context_t context;
char * key = "********";
unsigned char * out = NULL;
int i=0;
out = malloc(res-4);
rc4_init(&context,key,16);
rc4_encrypt(&context,req.data+4,out,res-4);
for(i=0;i<res-4;i++)
{
req.data[i] = out[i];
}
free(out);
req.data[res-4] = '/0';
res = res-4;
req.len = res;
}
.....

⑽ 傳輸層協議除了TCP和UDP還有什麼協議

傳輸層協議除了TCP和UDP還有TLS協議。TLS利用密鑰演算法在互聯網上提供端點身份認證與通訊保密，其基礎是公鑰基礎設施。

不過在實現的典型例子中，只有網路服務者被可靠身份驗證，而其客戶端則不一定。這是因為公鑰基礎設施普遍商業運營，電子簽名證書通常需要付費購買。協議的設計在某種程度上能夠使主從架構應用程序通訊本身預防竊聽、干擾和消息偽造。

(10)udp傳輸加密擴展閱讀

TLS協議的優勢是與高層的應用層協議（如HTTP、FTP、Telnet等）無耦合。應用層協議能透明地運行在TLS協議之上，由TLS協議進行創建加密通道需要的協商和認證。應用層協議傳送的數據在通過TLS協議時都會被加密，從而保證通信的私密性。

TLS協議可選的，必須配置客戶端和伺服器才能使用。主要有兩種方式實現這一目標：一個是使用統一的TLS協議通信埠（例如：用於HTTPS的埠443）；另一個是客戶端請求伺服器連接到TLS時使用特定的協議機制（例如：郵件、新聞協議和STARTTLS）。

一旦客戶端和伺服器都同意使用TLS協議，他們通過使用一個握手過程協商出一個有狀態的連接以傳輸數據。通過握手，客戶端和伺服器協商各種參數用於創建安全連接：

當客戶端連接到支持TLS協議的伺服器要求創建安全連接並列出了受支持的密碼組合（加密密碼演算法和加密哈希函數），握手開始。