SLENDER ANKLES's 개발블로그

TCP Three-way HandShaking 이란?

클라이언트와 서버가 통신하기 전 세 번의 패킷 교환을 통해 확인하는 과정을 말합니다.

TCP Three-way HandShaking의 과정

- CLIENT에서 웹 서버로 연결을 최초시도시 먼저 SYN 패킷을 보냅니다.

- SYN 패킷을 보낸 CLIENT는 SYN-SENT 상태가 됩니다.

- SERVER에서 CLOSED는 PORT가 닫혀있는 상태를 뜻하고, 포트가 서비스 가능한 상태인 LISTEN상태로 만들어주어야 합니다.

- LISTEN상태에서 CLIENT로부터 SYN패킷을 받으면 이에 대한 응답으로 SYN + ACK 패킷을 CLIENT로 보냅니다.

- SERVER는 CLIENT IP에 대해 포트 SYN-RECEIVED 상태로 전환됩니다.

- SERVER로부터 SYN+ACK 패킷을 받으면, CLIENT는 ESTABLISHED상태로 변하게 되면서 연결을 확인합니다.

- CLIENT는 SERVER로 SYN에 대한 응답으로 ACK패킷을 보냅니다.

- SERVER는 이 ACK 패킷을 받고 해당 CLIENT IP에 대한 포트 ESTABLISHED상태로 전환됩니다.

- 이로써 SERVER와 CLIENT의 TCP 3-WAY HandShaking 과정을 마치게 됩니다.

Code Bit(TCP Header)

TCP Header에는 Code Bit라는 항목이 있습니다. 이는 6bit로 되어있으며 각각의 bit는 의미를 가지고 있습니다.

URG - ACK - PSH - RST - SYN - FIN 순서로 되어 있으며 해당 위치의 비트에 1이 들어가게 되면 이 패킷의 어떤 패킷인가를 알려주게 됩니다. 즉 000010이라고 하면 SYN 패킷이 되는 겁니다.

Sequence Number

Sequence Number과 Acknowledgemnet Number이 있는데 TCP가 패킷을 주고 받을 때 순서와 Date와 관련됩니다. 

여기서 간단하게 설명하자면, 최초 TCP 3-way HandShaking과정을 Sequence Number과 Acknowledgement Number로 나타내겠습니다.

처음 클라이언트에서 SYN패킷을 보낼 때 Sequence Number(A)에 랜덤으로 숫자를 넣어서 보냅니다. 

여기서는 1이라고 하겠습니다. 서버가 이 SYN패킷을 받게 되면 응답으로 SYN+ACK패킷을 보내게 되는데, 

서버에서 보내는 Sequence Number(B)의 경우 또 랜덤의 숫자를 보내게 됩니다. 

여기서는 편의상 70이라고 하겠습니다. Acknowledgement Number의 경우, 앞 클라이언트에서 보내온 

SYN패킷의 Sequence Number에다 +1을 하여 보내게 됩니다.(A+1). 

즉 여기서는 Sequence Number가 2가 됩니다. 마지막으로 클라이언트에서 서버로부터 오는 

SYN + ACK를 받고 응답으로 ACK 패킷을 보내게 되는데 이때 서버에서 받은 Sequence Number에다 + 1을 

하여 보냅니다.

(B+1) 즉 71이라는 숫자를 Sequence Number로 보내게 됩니다.

참조 : http://cafe.naver.com/nsis/41903

우선 쉽게 설명하겠습니다.

비동기(Asynchronous)

우선 비동기란 말 그대로 동시에 일어나지 않는다는 의미입니다. 무엇이 같이 일어나지 않는 것일까? 바로 요청과 결과가 동시에 일어나지 않을 것이라는 약속입니다. 즉 요청한 즉시 응답해주는 것이 아니라 이따가라도 줄께라는 의미입니다.

동기(Synchronous)

동기란 말 그대로 동시에 일어난다는 의미입니다. 무엇이 같이 일어나는 것인가? 바로 요청과 결과가 동시에 일어난다는 약속입니다. 즉 요청한 즉시 응답해준다는 것입니다.

빅 엔디안과 리틀 엔디안의 차이에 대해서 설명해보겠다.

아주 간략하게 설명하고, 필요하다면 사족을 붙여야겠다.

바이트 오더?

바이트를 배열하는 방법을 말한다. 그 배열하는 방법을 엔디안(Endian)이라고 한다.

빅 엔디안(Big Endian)

주로 Unix시스템인 RISC프로세서 계열에서 사용하는 바이트 오더이다. 

메모리 시작 주소가 상위 바이트부터 기록된다는 것.

* 메모리 시작 주소에 상위 바이트부터 기록*

ex) 4바이트(32bit)값 0x01020304 를 빅엔디안 순서로 메모리에 입력되는 과정을 보면 다음과 같다.

그림을 설명하자면 네모 한칸이 메모리 한 번지를 의미하며, 하위 주소에서 상위 주소로 주소 번지가 증가함을 의미한다. 

리틀 엔디안(Little Endian)

주로 인텔(Intel)프로세스 계열에서 사용하는 바이트 오더이다. 

메모리 시작 주소가 하위 바이트부터 기록된다는 것.

* 메모리 시작 주소에 하위 바이트부터 기록*

ex) 4바이트(32bit)값 0x01020304 를 리틀엔디안 순서로 메모리에 입력되는 과정을 보면 다음과 같다.

그림을 설명하자면 네모 한칸이 메모리 한 번지를 의미하며, 상위 주소에서 하위 주소로 주소 번지가 증감함을 의미한다. 

** 쉽게 설명하자면 빅 엔디안은 왼쪽에서 오른쪽으로, 리틀 엔디안은 오른쪽에서 왼쪽으로 읽으면 된다. 

네트워크 바이트 오더?

네트워크 상에서 표준으로 이용되는 프로토콜은 네트워크 바이트 오더인 빅 엔디안이다.

GET과 POST 요청 방식의 차이는 무엇인가?

URL에 데이터가 있는 것은 GET방식, URL에 데이터가 없고 메시지 본문에 있는 것은 POST방식

GET요청의 특징

- URL에 데이터를 포함 - 데이터 조회에 적합

- 바이너리 및 대용량 데이터 전송 불가

- 요청라인과 헤드 필드의 최대 크기

  * HTTP 사양에는 제한사항 없음

  * 대용량 URL로 인한 문제 발생 => 웹 서버에 따라 최대 크기 제한

  * 마이크로소프트 IIS 6.0 16KB

  * APACHE 웹 서버 8KB

GET요청의 데이터 전달 형식은 어떻게 되는가?

서비스 주소 ? V1 = 23 & V2 = 15

서비스주소와 데이터를 ? 라는 문자를 이용해서 구분한다.

예) http://www.naver.com?v1=23&v2=15

GET 요청의 장점은 무엇인가?

URL에 데이터가 섞여 있기 때문에 결과 화면을 다른 사람들과 공유 할 수 있다. 

링크를 클릭하게 되면 바로 결과화면을 볼 수 있다.

GET 요청의 문제점은 무엇인가?

(1) 보안에 좋지 않다.

주소에 데이터가 섞여있기 때문에 사용자의 로그인이나 중요 정보 요청에서 데이터가 밖으로 보인다.

그렇기 때문에 보안상의 이슈가 발생 할 수 있다. 

(2) 바이너리 데이터를 전송 할 수 없다.

파일의 데이터는 URL에 붙여서 전송 할 수 없다.

BASE 64라는 인코딩 방식을 통해 바이너리 데이터를 문자화해서 보낼 수도 있지만, URI나 헤더 정보가 너무 크면

웹 서버에서 처리 할 수 없다.

이런 것은 POST를 통해 전송해야 한다.

POST요청의 특징

- URL에 데이터가 포함되지 않음 => 외부 노출 방지

- 메시지본문에 데이터 포함 => 실행 결과 공유 불가

- 바이너리 및 대용량 데이터 전송 가능

POST요청의 요청은 어떻게 이루어지는가?

요청라인과 요청헤더 다음에 공백라인이 있고 그 다음에 메시지 본문(Message Body)라 불리는 부분에 데이터가 위치해서 전송된다.

POST요청의 장점은 무엇인가?

입력값을 URL에 노출 시키지 않는다. 당연히 보안상으로 GET에 비해 좋다.

폼 태그를 통해 보내진 POST데이터는 Content-Length 와 Content-Type 등으로 구분한다.

Content-Type은 기본적으로 application/x-www-form-urlencoded형식으로 인코딩되어 보내진다.

POST요청의 문제점은 무엇인가?

(1) 요청 결과를  공유 할 수 없다.

즐겨찾기, 메일 등으로 그 결과값을 공유 할 수 없다.

POST요청은 데이터를 메시지 본문에 붙여서 전송하기 때문이다.

(2) GET방식과 마찬가지로 POST도 데이터를 전달 할 때 '이름=값&이름=값'형태로 보내진다.

결국 문자데이터를 보낼 때는 상관없지만 바이너리 데이터 등을 전송할 때는 이러한 '='이나 '&'값이 섞여 있을 수 있기 때문에 문제가 발생할 수 있다.

그래서 바이너리 데이터 등을 보낼 때는 멀티 파트 인코딩 방식을 통해 보내야 한다.

멀티 파트 인코딩 방식은 어떨때 사용하며 그렇게 사용하는 이유는 무엇인가?

POST형식 역시 데시지 본문에 '이름=값&이름=값'형태로 보내지기 때문에 

바이너리 데이터에 혹시 = 이나 &가 섞여있으면 문제가 발생 할 수 있다.

그래서 멀티 파트 인코딩 방식을 사용하여 요청정보와 데이터를 확실히 구분 할 수 있게 한다.

예를들어 <form>태그의 enctype 속성을 'multipart/form-data'로 지정해서 file 전송을 할 수 있게 합니다.

https는 전자상거래에서의 보안을 위해서 개발한 통신 레어이다.

SSL은 전송계층 프로토콜이기 때문에, 응용 계층의 어떠한 프로토콜이라도 암호화해서 보낼 수 있다.

HTTP는 기본적으로 평문 데이터 전송을 원칙으로 하기 때문에 개인의 프라이버시와 관련된 보안적으로는 활용하기 힘들다.

HTTPS는 SSL레이어 위에 HTTP를 통과시키는 방식이다. 평문의 HTTP문서는 SSL레이어를 통과하면서 암호화돼서 목적지에 도착하고, 목적지에는 SSL레이어를 통과하면서 복호화돼서 웹브라우저에 전달된다.

- HTTP와 다른점?

HTTPS는 인증서를 이용해서, 접속사이트를 신뢰할 수 있는지 평가할 수 있다.

HTTPS는 HTTP에 비해 느리다. 

HTTP 프로토콜 이란?

HTTP 프로토콜은 웹 브라우저와 웹 서버 사이의 데이터 통신 규칙을 말한다.

즉 HTTP 통신 규약에 맞추어서 요청한다면

HTML파일을 요청하면 HTML파일을 보내주고, 이미지 파일을 요청하면 이미지 파일을 보내준다는 것이다.

http요청 응답에 대한 내부적으로 어떻게 동작하고 있는가?

요청과정(Request)

요청라인, 요청헤더, 공백라인과 요청 데이터로 구성

GET /web04/member/list HTTP/1.1

Host: localhost:9999

Cache-Control: max-age=0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36

Accept-Encoding: gzip, deflate, sdch

Accept-Language: ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4

요청 라인(Request-Line)

요청헤더

  * 요청이나 응답 모두에 적용 할 수 있는 "일반헤더(General Header)"

  * 요청 또는 응답 둘 중에 하나에만 적용 할 수 있는 "요청 헤더 또는 응답 헤더(Request Header / Response Header)"

  * 보내거나 받는 본문 데이터를 설명하는 "엔티티 헤더(Entity-Header)"

HTTP헤더들

GET요청 

공백 라인으로 끝납니다. 서버에 보낼 데이터가 있다면 URL주소에 붙여 보냅니다.

POST요청

그에 비해 로그인이나 게시글을 등록하는 경우 POST를 사용하는데, POST요청은 공백 라인 다음에 메시지 본문이 들어갑니다.

응답과정(Response)

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Content-Type: text/html;charset=UTF-8

Content-Length: 1138

Date: Sun, 12 Jul 2015 07:16:42 GMT

<html><head><title>회원목록</title></head>

<body><h1>회원목록</h1>

http는 웹브라우저와 웹 서버간의 통신을 위한 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 동작한다.

요청과정, 응답과정으로 이루어져 있습니다.

요청메시지는

RequestLine - Header - 공백 - Body

RequestLine에는 GET, POST와 같은 메소드와 URL, HTTP버젼 등이 포함되며

헤더에는 HTTP프로토콜을 통해 전송할 정보들을 다루는 헤더를 포함시킵니다.

공백을 하나 두고 POST요청과 같은 경우 본문 메세지를 보냅니다.

응답메시지는

status line - Header - 공백 - Body로 구성되바니다.

STATUS LINE은 200, 404 등등 상태 번호와 버젼 등이 작성되어 전달되며,

헤더와 공백과 함께 POST와 같은 경우 BODY가 함께 전송됩니다.

요청과정는 요청라인과 요청헤더로 이루어져 있는데, GET, POST 등의 메서드와 요청 URI 등이 전달되며

요청 헤더에 필요한 정보들이 섞여 들어갑니다. 예를 들어 Cache-control같은 일반헤더, UserAgent, Host와 같은 요청헤더

GET요청과 같은 경우에는 본문 메시지를 넣지 않고, POST요청과 같은 경우에는 이러한 헤더 밑에 본문 메세지를 같이 보내게 됩니다.

응답과정은 응답에 대한 상태코드와 헤더, 그 아래에 메시지 본문을 같이 보내게 됩니다.

- http란 무엇인지에 대해서

HyperText Transfer Protocol : 하이퍼텍스트 기반으로 데이터를 전송하겠다는 뜻. 간단히 말하면 링크기반으로 데이터에 접속하겠다는 의미이다.

웹서버는 보통 표준포트 80번 포트로 서비스한다.

http는 connectionless방식으로 작동한다. 서버에 연결하고, 요청해서 응답을 받으면 연결을 끊어버린다. 기본적으로 자원하나에 대해서 하나의 연결을 만든다.

이런 방식에 대해서 장, 단점이 있는데

장점) 불특정 다수를 대상으로 하는 서비스에 적합한 방식. 수십만명이 사용하더라도 접속유지는 최소한으로 할 수 있기 때문에 더 많은 유저의 요청을 처리할 수 있음

단점) 연결을 끊어버리기 때문에 클라이언트의 이전 상태를 알 수 없다. 이러한 http의 특징을 stateless라고 하는데, connectless로 부터 파생되는 특징이다.

예컨데 이전에 로그인 접속이 되었는데도 그에 대한 정보를 알지 못하는 상황을 말한다. 이러한 문제를 http는 쿠키를 통해 해결하고 있다.(또는 세션에 의해서 처리하기도)

URI와 메서드

URI는 자원의 위치를 알려주기 위한 프로토콜이다. Uniform Resource Identifiers의 약자이다.

메서드는 GET, POST, PUT, DELETE 등의 메서드를 명세한다. 보통 GET과 POST만 있으면 되지만, RESTful API를 위해서

GET, POST, PUT, DELETE등의 메소드를 모두 활용하여 CRUD를 구성하는 것이 좋다.

HTTP 1.1부터는 KEEP-ALIVE 속성을 지원하는데 이 것은 무엇을 말하는가?

예를 들어 한 번의 웹 요청으로 많은 리소스들을 받게 되는데

HTML페이지, CSS, JS, 이미지 등등 그런데 KEEP-ALIVE속성이 없다면

다음과 같이 동작하게 될 것이다.

1) 웹서버에 연결한다.

2) HTML문서를 다운로드한다.

3) 웹서버를 끊는다.

4) HTML문서의 image, css, javascript 링크들을 읽어서 다운로드해야 할 경로를 저장한다.

5) 웹 서버에 연결한다.

6) 첫 번째 이미지를 다운로드

7) 연결을 끊는다.

8) 웹 서버에 연결한다.

9) 두 번째 이미지를 다운로드

10) 연결을 끊는다.

11) ....

Keep-Alive 속성은 연결의 시간을 정해두고, 동작하게 된다. 

Keep-Alive 속성을 이용해서 연결이 이루어지고 여러 요청을 한 꺼번에 처리하기 때문에 효율적이다.

하지만 그만큼 서버의 운영체제에서는 연결이라는 유한한 자원을 사용하고 있는 것이므로 최대 연결 개수를 설정해놓는다. 

저장되는 곳이 다르다. 쿠키는 클라이언트에 저장되고, 세션은 서버에 저장된다.

쿠키의 경우 서버의 자원을 전혀 사용하지 않지만, 세션의 경우에는 서버에 저장되기 때문에 서버의 자원을 사용 할 수 있다. 쿠키와 세션이 만료되는 기간도 다르다.

쿠키란 무엇인가?

(1) 쿠키란 서버측에서 클라이언트 측에 상태 정보를 저장하고 추출할 수 있는 메커니즘

(2) 클라이언트의 매 요청마다 웹 브라우저로부터 서버에게 전송되는 정보패킷의 일종

(3) HTTP에서 클라이언트의 상태 정보를 클라이언트의 하드 디스크에 저장하였다가 필요 시 정보를 참조하거나 재 사용 할 수 있음

(4) 사용 예) 방문했던 사이트에 다시 방문하였을 때 아이디와 비밀번호 자동 입력

** 하나의 도메인에서 설정한 쿠키값이 20개를 초과하면 가장 적게 사용된 쿠키부터 지워짐. 또한 쿠키는 기존에 설정한 값이 있는 곳에 저장하거나 배열형태의 쿠키에 단일 값을 저장하려고 할 때 아무런 경고 없이 덮어쓰기 때문에 주의를 해야 한다. 

세션이란 무엇인지?

(1) 세션이란 클라이언트와 웹서버 간에 네트워크 연결이 지속적으로 유지되고 있는 상태를 말함

(2) 클라이언트가 웹서버에 요청하여 처음 접속하면 JSP(혹은 ASP)엔진은 요청한 클라이언트에 대하여 유일한 ID를 부여하게 되는데, 이 ID를 세션이라고 한다.

(3) 세션 ID를 임시로 저장하여 페이지 이동 시 이용하거나, 클라이언트가 재 접속 했을 때 클라이언트를 구분 할 수 있는 유일한 수단이 된다.

(4) 세션의 장점

1) 각각의 클라이언트마다 고유 ID 부여

2) 세션 객체마다 저장해 둔 데이터를 이용하여 서로 다른 클라이언트의 요구에 맞게 서비스 제공

3) 클라이언트 자신만의 고유한 페이지를 열어놓아서 생길 수 있는 보안상의 문제 해결 용이

IP주소의 이진 주소 체계는 사람들이 기억하기 어렵기 때문에 도메인 네임을 통해 주소를 관리.

도메인 네임 서버를 통해 어떻게 IP주소를 얻어내는지에 대해서 알아보자.

1) PC자체 Cache를 확인하여 해당 도메인에 대한 IP정보(접속하려는 곳)을 탐색

    - IP정보발견시 -> 접속

    - 발견 못함-> 다음단계로

2) pc에서 지정한 Local DNS에 www.naver.com 질의

3) local DNS는 ROOT DNS에게 최상위 도메인(COM)에 대한 정보를 가진 네임서버를 질의

    - Cached 시 -> 다음 단계로 진행하지 않고, 바로 응답(최종목적지)

4) Local DNS는 COM ROOT에게 naver네임서버의 정보를 질의

    - cached 시 -> 다음 단계로 진행하지 않고, 바로 응답(최종목적지)

5) Local DNS는 naver네임서버에게 www.naver.com IP 정보를 질의

    - cached 시 -> 다음 단계로 진행하지 않고, 바로 응답(최종목적지)

6) 네이버 네임 서버가 www.naver.com의 IP를 제공하면, PC에서 접속(IP주소이용)

flow control(흐름 제어)

송신 측과 수신 측의 데이터 처리 속도 차이를 해결하기 위한 기법이다.

수신 측이 송신 측보다 속도가 빠른 것은 아무 문제가 없다. 하지만 송신 측이 수신 측보다 속도가 빠르면 문제가 발생한다.

수신 측에서 수신된 데이터를 처리해서 상위 계층으로 서비스 하는 속도보다 송신 측에서 보내는 데이터의 속도가 더 빠르다면 수신 측에서는 제한된 저장용량을 초과하여 이후에 도착하는 데이터는 손실될 수 있다. 만약 데이터가 손실 된다면 불필요하게 응답과 데이터의 재전송이 송신 측과 수신 측간에 빈번히 이동해야 한다.

따라서 이러한 위험을 줄이기 위해 송신 측의 데이터 전송 량을 수신 측의 에 따라 조절한다.

이러한 작업을 흐름 제어라고 한다.

(a) Stop and Wait 방식

(b) Windowing 방식

tcp흐름제어

TCP는 먼저 연결을 설정한 후에 전송을 시작하지만 수신 측의 처리 능력이나 네트워크 대역폭 문제로 세그먼트를 원활하게 전송하지 못할 수도 있다.

이를 위해 TCP는 송신 측 전송 속도를 제어하는 메커니즘인 슬라이딩 윈도우 기법을 사용한다.

(1) Sliding Window 정의

- TCP 슬라이딩 윈도우 기법은 수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법이다. 이처럼 슬라이딩 윈도우 기법을 통하여 송신 버퍼의 범위는 수신 측의 여유 버퍼 공간을 반영하여 동적으로 바뀜으로써 흐름제어를 수행하게 된다.

- 슬라이딩 윈도우는 일단 윈도우에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인 되는대로 이 윈도우를 옆으로 옮김(Slide)으로서 그 다음 패킷들을 전송하는 방식이다.

- 또한 윈도우의 크기만큼은 수신 쪽의 확인(응답)을 받지 않고도 보내는 것이 가능하므로 매번 전송한 패킷에 대해 확인을 받아야만 그 다음 패킷을 전송하는 방법(stop-and-wait)를 사용하는 것보다 훨씬 네트워크를 효율적으로 사용할 수 있다.

(2) window크기

- tcp/ip를 사용하는 모든 호스트들은 각각 2개의 window를 가지고 있다. 하나는 보내기 위한 window이며 또 다른 하나는 받기 위한 window이다.

- 호스트들은 실제 데이터를 보내기 전에 먼저 “TCP-3-way handshaking”을 통하여 수신컴퓨터의 receive window size에 자신의 send window size를 맞추게 된다. 즉 상대방이 받을 수 있는 크기에 맞추어 전송을 하겠다는 것이다.

- 즉 TCP 송신 윈도우 크기는 수신 측으로부터 확인응답 없이 전송할 수 있는 데이터의 개수를 의미한다. 윈도우 크기는 전송했으나 아직 확인 응답 받지 못한 데이터와 지연 없이 전송할 수 있는 데이터 크기를 합한 값이 된다.

congestion control(혼잡 제어)

- 송신 측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법이다. 송신 측의 데이터는 지역 망이나 인터넷으로 연결된 대형 네트워크를 통해 전달된다. 만약 한 라우터에 데이터가 몰릴 경우, 다시 말해 혼잡할 경우 라우터는 자신에게 온 데이터를 모두 처리 할 수 없다. 그렇게 되면 호스트들은 또 다시 재전송을 하게 되고 결국 더욱 더 혼잡만 가중시켜 오버플로우나 데이터 손실을 발생 시킨다. 따라서 이러한 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송 속도를 강제로 줄이게 된다. 이러한 작업을 혼잡 제어라고 한다.

- 또한 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡(Congestion)이라고 하며 혼잡 현상을 방지하거나 제거하는 기능을 혼잡제어(Congestion Control)라고 한다. 흐름제어가 송신 측과 수신 측 사이의 전송 속도를 다루는데 반하여 혼잡제어는 호스트와 라우터를 포함한 보다 넓은 관점에서의 전송 문제를 다룬다.

- 앞에서 본 흐름 제어는 두 장비 간의 데이터 송신을 통제하는 중요한 부분이지만 연결에 참여하는 두 장비의 상황만 고려할 뿐 두 장비 사이에 있는 라우터 같은 다른 장비는 고려하지 않는다. 이것은 사실 계층 구조상 당연한 일이지만, 실제로는 TCP가 3계층에서 어떤 일이 벌어지고 있는지 아는 것은 매우 중요하다. 왜냐하면 네트워크가 혼잡해지게 되면 라우터 버퍼들의 오버플로우가 발생하며 세그먼트를 송신하는 속도가 느려지거나 어떤 때에는 버려지기도 한다.

- 혼잡제어 알고리즘

(a) AIMD(Additive Increase / Multicative Decrease)

- 이 방식은 AIMD라고 불리는 방식이다. 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 창 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가면서 전송하는 방법이다. 만일 패킷 전송을 실패하거나 일정한 시간을 넘으면 패킷을 보내는 속도를 절반으로 줄이게 된다.

- 이 방식은 공평한 방식이다. 이 방식을 사용하는 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만 시간이 흐르면 평형 상태로 수렴하게 되는 특징이 있다.

- 문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지는 못한다. 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

(b) slow start

합 증가/곱 감소 방식이 네트워크의 수용량 주변에서는 효율적으로 작동하지만 처음에 전송 속도를 올리는 데 걸리는 시간이 너무 길다는 단점이 있다. 느린 시작(Slow Start) 방식은 합 증가/곱 감소 방식과 마찬가지로 패킷을 하나씩 보내는 것부터 시작한다. 그러나 이 방식은 패킷이 문제없이 도착하면 각각의 ACK 패킷마다 창 크기를 1씩 늘린다. 즉, 한 주기가 지나면 창 크기가 2배로 된다. 따라서 전송 속도는 합 증가/곱 감소와는 다르게 지수 함수 꼴로 증가한다. 대신에 혼잡 현상이 발생하면 창 크기를 1로 떨어뜨린다. 처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있으므로 혼잡 현상이 발생하였던 창 크기의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시킨다.

(c) Fast Retransmit(빠른 재전송)

빠른 재전송은 TCP의 혼잡 조절에 추가된 정책이다. 패킷을 받는 쪽에서 먼저 도착해야 할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보낸다. 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보낸다. 따라서 중간에 패킷 하나가 손실되게 되면 보내는 측에서는 순번이 중복된 ACK 패킷을 받게 되고, 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송해 줄 수 있다. 빠른 재전송은 중복된 순번의 패킷을 3개 받으면 재전송을 한다. 그리고 이런 현상이 일어나는 것은 약간 혼잡한 상황이 일어난 것이므로 혼잡을 감지하고 창 크기를 줄이게 된다.

(d) Fast Recovery(빠른 회복)

빠른 회복 정책은 혼잡한 상태가 되면 창 크기를 1로 줄이지 않고 반으로 줄이고 선형 증가시키는 방법이다. 빠른 회복 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 합 증가/곱 감소 방식으로 동작한다.

이러한  TCP의 성질 때문에 Reliable한 특징을 가지는 것!

TCP는 UDP와 달리 연결지향이라고 배웠었다. 그렇다면 연결지향이란 무엇을 의미하는것일까 ? 우리는 바로 위에서 TCP/IP 에 의해서 데이타가 어떻게 전송되어지는지를 알아봤는데, 데이타가 전송되기전에, Browser 와 Server 간의 연결을 성립하는 과정이 데이타를 전송하는 과정전에 이루어지게 된다. 연결을 만드는 과정은 이를테면 우리가 전화할때 어떤내용을 말하기에 앞서서, "안녕하세요 ?" "누구누구씨 맞아요" "아내 저 누구누구 맞습니다"라고 상대편을 먼저 확인하는 과정과 동일한 과정이다.

즉 데이타가 전송되기 전에, 먼저 Browser 는 Server 에 "서버 잘있읍니까?" 라고 메시지를 보내고, Server 는 다시 Browser(:12) 에게 "서버 준비되어 있으니, 데이타 보내시요" 라는 메시지를 보내고 Browser 는 다시 서버에게 "네, 그럼 지금부터 데이타를 보내겠습니다" 라고 서로 의 존재를 확인하는 절차를 수행한후, 정식 데이타를 교환하기 위한 통신선로를 개설하게 된다. 통신선로를 하나 만들기 위해서는 3번의 데이타 전송이 일어나게 되므로, 이것을 three way handshake이라고 한다. 위 그림은 three way handshake 의 과정을 보여주고 있다.

이렇게 연결이 이루어지면 모든 정식데이타는 연결된 통신선로를 통해서 교환되게 되며, 이러한 이유로 TCP를 "연결 지향" 프로토콜이라고 부르는 것이다. UDP 는 이러한 과정이 없이 단순히 데이타만을 전송함으로 "데이타 그램" 프로토콜이라고 부른다.