y-log

OSI 7계층

표준화를 통해 이질적인 포트 문제나 프로토콜 등으로 인한 문제를 해결하여 비용을 절감했다.
또한, 계층별의 기능과 통신 과정을 단계별로 나누어서 쉽게 알 수 있고, 특정한 곳에 이상이 생기면 그 단계만 수정할 수 있기 때문에 편리하다.

1) 물리(Physical)

리피터, 케이블, 허브 등

주로 전기적, 기계적, 기능적인 특성을 이용해서 통신 케이블로 데이터를 전송하는 역할을 한다.

2) 데이터 링크(Data Link)

브릿지, 스위치 등

물리 계층을 통해 송, 수신되는 정보의 오류와 흐름을 관리하여 안전한 정보의 전달을 수행할 수 있도록 도와주는 역할을 한다.

MAC 주소를 이용해 통신한다.

Frame에 MAC 주소를 부여하고 에러검출, 재전송, 흐름 제어를 진행한다.

3) 네트워크(Network)

라우터, IP

여러 개의 노드를 거칠 때마다 경로를 찾아주는 역할을 하며, 다양한 길이의 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능을 담당한다. (전송 계층이 요구하는 서비스 품질을 제공하기 위한 기능적, 절차적 수단을 제공한다.)

라우터를 통해 이동할 경로를 선택하여 IP 주소를 지정하고, 해당 경로에 따라 패킷을 전달해준다.

라우팅, 흐름 제어, 오류 제어, 세그먼테이션 등을 수행한다.

4) 전송 계층(Transport)

TCP, UDP

TCP, UDP 프로토콜을 통해 통신을 활성화 한다. 포트를 열어두고, 프로그램들이 전송을 할 수 있도록 제공해준다. 이를 통해 양 끝 단의 사용자들이 데이터를 주고 받을 수 있다.

• TCP : 신뢰성, 연결 지향적
• UDP : 비신뢰성, 비연결성, 실시간

TCP 프로토콜(Transmission Control Protocol)

OSI 계층모델의 관점에서 전송 계층(4계층)에 해당

양종단 호스트 내 프로세스 상호 간에 신뢰적인 연결지향성 서비스를 제공

- IP의 비신뢰적인 최선형 서비스에다가 신뢰적인 연결지향성 서비스를 제공하게 됨

. 신뢰적인 전송을 보장함으로써, 어플리케이션 구현이 한층 쉬워지게 됨

1. 신뢰성 있음 (Reliable)

패킷 손실, 중복, 순서바뀜 등이 없도록 보장

TCP 하위계층인 IP 계층의 신뢰성 없는 서비스에 대해 다방면으로 신뢰성을 제공

2. 연결지향적 (Connection-oriented)                                        ☞ TCP 연결

같은 전송계층의 UDP가 비연결성(connectionless)인 것과는 달리, TCP는 연결지향적 임

이 경우, 느슨한 연결(Loosly Connected)을 갖으므로 강한 연결을 의미하는 

가상회선이라는 표현 보다는 오히려 연결지향적이라고 말함

연결 관리를 위한 연결설정 및 연결해제 필요          ☞ TCP 연결설정, TCP 연결종료

양단간 어플리케이션/프로세스는 TCP가 제공하는 연결성 회선을 통하여 서로 통신

UDP 프로토콜(User Datagram Protocol)

전송 계층의 통신 프로토콜의 하나 (TCP에 대비됨)

- 신뢰성이 낮은 프로토콜로써 완전성을 보증하지 않으나,  

- 가상회선을 굳이 확립할 필요가 없고 유연하며 효율적 응용의 데이타 전송에 사용

1. 비연결성이고, 신뢰성이 없으며, 순서화되지 않은 Datagram 서비스 제공 

- 메세지가 제대로 도착했는지 확인하지 않음 (확인응답 없음)

- 수신된 메세지의 순서를 맞추지 않음 (순서제어 없음) 

- 흐름 제어를 위한 피드백을 제공하지 않음 (흐름제어 없음)

- 검사합을 제외한 특별한 오류 검출 및 제어 없음 (오류제어 거의 없음)

UDP를 사용하는 프로그램 쪽에서 오류제어 기능을 스스로 갖추어야 함

- 데이터그램 지향의 전송계층용 프로토콜 (논리적인 가상회선 연결이 필요없음)

비연결접속상태 하에서 통신 

2. 실시간 응용 및 멀티캐스팅 가능

- 빠른 요청과 응답이 필요한 실시간 응용에 적합

- 여러 다수 지점에 전송 가능 (1:多)

3. 헤더가 단순함

- UDP는 TCP 처럼 16 비트의 포트 번호를 사용하나,

- 헤더는 고정크기의 8 바이트(TCP는 20 바이트) 만 사용

즉, 헤더 처리에 많은 시간과 노력을 요하지 않음

5)세션(Session)

API, Socket

데이터가 통신하기 위한 논리적인 연결을 말한다. 통신을 하기위한 대문이라고 보면 된다.

하지만 4계층에서도 연결을 맺고 종료할 수 있기 때문에 우리가 어느 계층에서 통신이 끊어 졌나 판단하기는 한계가 있다. 

그러므로 세션 계층은 4 계층과 무관하게 응용 프로그램 관점에서 봐야 한다. 

세션 설정, 유지, 종료, 전송 중단시 복구 등의 기능이 있다.

세션 계층(Session layer)은 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다. 

동시 송수신 방식(duplex), 반이중 방식(half-duplex), 전이중 방식(Full Duplex)의 통신과 함께, 체크 포인팅과 유휴, 종료, 다시 시작 과정 등을 수행한다. 

이 계층은 TCP/IP 세션을 만들고 없애는 책임을 진다.

-> 

통신하는 사용자들을 동기화하고 오류복구 명령들을 일괄적으로 다룬다. 

통신을 하기 위한 세션을 확립/유지/중단 (운영체제가 해줌)

6) 표현(Presentation)

JPEG, MPEG 등

데이터 표현에 대한 독립성을 제공하고 암호화하는 역할을 담당한다.

코드 간의 번역을 담당하여 사용자 시스템에서 데이터의 형식상 차이를 다루는 부담을 응용 계층으로부터 덜어준다.

파일 인코딩, 명령어를 포장, 압축, 암호화한다.

7) 응용(Application)

HTTP, FTP, DNS 등

최종 목적지로 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.

사용자 인터페이스, 전자우편, 데이터베이스 관리 등의 서비스를 제공한다.

웹

WWW world wide web의 약자

인터넷을 통해 접근할 수 있는 정보 공간
URL로 문서등 리소스를 식별하고, 리소스 간 하이퍼링크로 연결될 수 있다

웹 통신 

• 클라이언트 : 사용자가 서버에 접속하기 위해 사용하는 프로그램 또는 서비스. 웹 브라우저, 모바일 앱 등
• 서버 : 클라이언트에게 네트워크를 통해 정보나 서비스를 제공하는 컴퓨터 시스템

웹 통신 과정

1. 사용자가 웹 브라우저를 통해 URL을 입력한다
2. 입력된 URL 중 도메인 네임을 DNS 서버에서 검색한다
3. DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달한다
4. 웹 페이지 URL 정보와 전달받은 IP 주소를 이용해 HTTP 요청 메시지를 생성한다
5. 요청은 TCP를 통해 서버로 전송된다
6. 서버는 클라이이너트의 요청을 받고 응답을 전송한다

DNS의 웹/앱 라우팅 과정

1. 사용자가 웹 브라우저 주소창에 www.example.com을 입력
2. www.example.com에 대한 요청이 인터넷 서비스 제공업체(ISP)가 관리하는 DNS 해석기로 라우팅
3. DNS 해석기는 요청을 DNS 루트 이름 서버에 전달
4. DNS 해석기는 요청을 .com 도메인 TLD(Top-level Domain) 네임 서버 중 하나에 다시 전달
5. DNS 해석기는 요청을 Route 53 네임 서버에 다시 전달
6. Route 53 네임 서버는 www.example.com 레코드를 찾아 IP주소를 DNS 해석기로 반환
7. DNS 해석기는 웹 브라우저에 IP주소 반환

❗우리가 Chrome 을 실행시켜 주소창에 특정 URL 값을 입력시키면 어떤 일이 일어나는가?

in 브라우저

1. url 에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 그 의미를 조사한다.
2. 조사된 의미에 따라 HTTP Request 메시지를 만든다.
3. 만들어진 메시지를 웹 서버로 전송한다.

이 때 만들어진 메시지 전송은 브라우저가 직접하는 것이 아니다. 브라우저는 메시지를 네트워크에 송출하는 기능이 없으므로 OS에 의뢰하여 메시지를 전달한다. 우리가 택배를 보낼 때 직접 보내는게 아니라, 이미 서비스가 이루어지고 있는 택배 시스템(택배 회사)을 이용하여 보내는 것과 같은 이치이다. 단, OS에 송신을 의뢰할 때는 도메인명이 아니라 ip주소로 메시지를 받을 상대를 지정해야 하는데, 이 과정에서 DNS서버를 조회해야 한다.

in 프로토콜 스택, LAN 어댑터

1. 프로토콜 스택(운영체제에 내장된 네트워크 제어용 소프트웨어)이 브라우저로부터 메시지를 받는다.
2. 브라우저로부터 받은 메시지를 패킷 속에 저장한다.
3. 그리고 수신처 주소 등의 제어정보를 덧붙인다.
4. 그런 다음, 패킷을 LAN 어댑터에 넘긴다.
5. LAN 어댑터는 다음 Hop의 MAC주소를 붙인 프레임을 전기신호로 변환시킨다.
6. 신호를 LAN 케이블에 송출시킨다.

프로토콜 스택은 통신 중 오류가 발생했을 때, 이 제어 정보를 사용하여 고쳐 보내거나, 각종 상황을 조절하는 등 다양한 역할을 하게 된다. 네트워크 세계에서는 비서가 있어서 우리가 비서에게 물건만 건네주면, 받는 사람의 주소와 각종 유의사항을 써준다! 여기서는 프로토콜 스택이 비서의 역할을 한다고 볼 수 있다.

in 허브, 스위치, 라우터

1. LAN 어댑터가 송신한 프레임은 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착한다.
2. 라우터는 패킷을 프로바이더(통신사)에게 전달한다.
3. 인터넷으로 들어가게 된다.

in 액세스 회선, 프로바이더

1. 패킷은 인터넷의 입구에 있는 액세스 회선(통신 회선)에 의해 POP(Point Of Presence, 통신사용 라우터)까지 운반된다.
2. POP 를 거쳐 인터넷의 핵심부로 들어가게 된다.
3. 수 많은 고속 라우터들 사이로 패킷이 목적지를 향해 흘러가게 된다.

in 방화벽, 캐시서버

1. 패킷은 인터넷 핵심부를 통과하여 웹 서버측의 LAN 에 도착한다.
2. 기다리고 있던 방화벽이 도착한 패킷을 검사한다.
3. 패킷이 웹 서버까지 가야하는지 가지 않아도 되는지를 판단하는 캐시서버가 존재한다.

굳이 서버까지 가지 않아도 되는 경우를 골라낸다. 액세스한 페이지의 데이터가 캐시서버에 있으면 웹 서버에 의뢰하지 않고 바로 그 값을 읽을 수 있다. 페이지의 데이터 중에 다시 이용할 수 있는 것이 있으면 캐시 서버에 저장된다.

in 웹 서버

1. 패킷이 물리적인 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘긴다.
2. 메시지를 받은 웹 서버 애플리케이션은 요청 메시지에 따른 데이터를 응답 메시지에 넣어 클라이언트로 회송한다.
3. 왔던 방식대로 응답 메시지가 클라이언트에게 전달된다.

Reference.

link1 link2 

DNS란
Domain Name System

www.xxx.com 과 같이 사람이 읽을 수 있는 이름을
192.0.0.1 과 같은 숫자 IP주소로 변환하여
컴퓨터가 서로 통신할 수 있도록 도와주는 서버

• DNS 시스템은 이름을 숫자로 매핑하여 전화번호 부와 같은 역할을 한다.
• DNS 서버는 이름에 대한 요청을 IP 주소로 변환하여, 최종 사용자가 도메인 이름을 웹 브라우저에 입력할 때 해당 사용자를 어떤 서버에 연결할 것인지 제어한다. --> 이 요청을 쿼리라고 한다.

1. DNS Query
    DNS 서버에서 domain name을 이용하여 IP를 받아온다
2. IP Communication
    IP를 받아온 유저는 리퀘스트 메세지 발송을 통하여 정상적으로 네트워크 통신을 실시한다

DNS 동작원리

1. 사용자가 www.naver.com 을 브라우저에 입력한다.
2. Local DNS에게 IP 주소를 질의하여 캐시된 것에 없으면 다른 DNS 서버에 전달 (Root DNS)
3. ROOT 로 부터 com 도메인을 관리하는 TLD이름 서버 정보 전달 받는다.
4. COM DNS로 질의 한다.
5. naver.com DNS 정보를 전달 받는다.
6. www.naver.com 호스트네임에 대한 IP 주소를 질의 한다.
7. IP 정보를 전달받는다.
8. Local DNS는 www.nvaer.com에 대한 IP 주소를 캐싱을 하고 IP 주소 정보를 전달한다.

※ ROOT -> COM -> xxx.com 서버를 차례대로 질의해서 답을 찾는 과정을 Recursive Query라고 한다.

DNS Round Robin

round robin이란 DNS 서버 구성 방식 중 하나다.
Domain에 대한 IP요청 

원리

• 웹 서비스를 담당할 여러 대의 웹 서버는 자신의 공인 IP를 각각 가지고 있다.
• 사이트 접속을 위해 사용자가 해당 도메인 주소를 브라우저에 입력하면 DNS는 도메인의 정보를 조회하는데 이떄 IP주소를 여러 대의 서버 IP리스트 중에서 라운드 로빈 형태로 랜덤하게 하나 혹은 여러개를 선택하여 사용자에게 알려준다.
• 결과적으로 웹 사이트에 접속하는 다수의 사용자는 실제로는 복수의 웹 서버에 나뉘어 접속하도 되면서 자연스럽게 서버의 부하가 분산되는 방식이다.

라운드 로빈 DNS는 여러개의 IP주소를 결과로 돌려준다.

사용자의 OS 애플리케이션에 따라 동작이 다르다.
여러개의 IP 중 제일먼저 조회된 IP를 선택, 무작위로 IP를 선택한다.
또는 선택 IP 접속이 안되면 그다음 조회된 IP접속하도록 호직을 추가할 수 있다.

단점

1. 서버의 수 만큼 공인 IP 주소가 필요합니다.
부하 분산을 위해 서버의 대수를 늘리기 위해서는 그 만큼의 공인 IP 가 필요합니다.

2. 균등하게 분산되지 않습니다.
모바일 사이트 등에서 문제가 될 수 있는데, 스마트폰의 접속은 캐리어 게이트웨이 라고 하는 프록시 서버를 경유 합니다.
프록시 서버에서는 이름변환 결과가 일정 시간 동안 캐싱되므로 같은 프록시 서버를 경유 하는 접속은 항상 같은 서버로 접속됩니다.
또한 PC 용 웹 브라우저도 DNS 질의 결과를 캐싱하기 때문에 균등하게 부하분산 되지 않습니다.
DNS 레코드의 TTL 값을 짧게 설정함으로써 어느 정도 해소가 되지만, TTL 에 따라 캐시를 해제하는 것은 아니므로 반드시 주의가 필요하다.

3. 서버가 다운되도 확인이 불가능합니다.
DNS 서버는 웹 서버의 부하나 접속 수 등의 상황에 따라 질의결과를 제어할 수 없다.
웹 서버의 부하가 높아서 응답이 느려지거나 접속수가 꽉 차서 접속을 처리할 수 없는 상황인 지를 전혀 감지할 수가 없기 때문에 어떤 원인으로 다운되더라도 이를 검출하지 못하고 유저들에게 제공됩니다.
이때문에 유저들은 간혹 다운된 서버로 연결이 되기도 하죠.
DNS 라운드 로빈은 어디까지나 부하분산 을 위한 방법이지 다중화 방법은 아니므로 다른 S/W 와 조합해서 관리할 필요가 있다.

해결법

다중화 구성 방식 (Synchronous Time-Division Multiplexing)
AP 서버에 VIP(Virtual IP)를 부여해서 다중화를 구성한다. 각 AP 서버를 Health Check후 이상이 감지되면 VIP를 정상 AP 서버로 인계하는 방식을 사용한다.
즉 DNS Server Table 에 실시간으로 AP 서버의 상태를 확인할 수 있는 칼럼 및 함수를 추가하여 요청될 경우 서버 상태를 확인하여 우회루트를 제공하거나 에러를 전송하는 방식을 말합니다.

가중치 편성 방식 (Weighted round robin)
각각의 웹 서버에 가중치를 가미해서 분산 비율을 변경한다. 물론 가중치가 큰 서버일수록 빈번하게 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋다.


또 다른 방법으로는 로드 밸런서의 도입을 통하여 다음과 같은 구성도 가능

최소 연결 방식 (Least connection)
접속 클라이언트 수가 가장 적은 서버를 선택한다. 로드밸런서에서 실시간으로 connection 수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요하다.

Reference.

link1 link2

HTTP란

Hyper Text Transfer Protocol
www상에서 정보를 주고받는 프로토콜

클라이언트인 웹 브라우저가 서버에 HTTP를 통해 웹페이지나 이미지 정보를 요청하면, 서버는 이 요청에 응답하여 요구하는 정보를 제공하게 된다.

HTTP는 웹 브라우저Client와 서버Server간의 웹페이지 같은 자원을 주고 받을 때 쓰는 통신 규약이다.

HTTP는 텍스트 교환이라 (html페이지도 텍스트!) 누군가 네트워크에서 신호를 가로채 본다면 내용이 노출될 것이다.

이와같은 보안상의 문제를 해결해주는 프로토콜이 HTTPS이다.

" HTTP의 문제점 "

• HTTP 는 평문 통신이기 때문에 도청이 가능하다.
• 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
• 완전성을 증명할 수 없기 때문에 변조가 가능하다.

* 위와 같은 문제점은 암호화하지 않은 다른 프로토콜에도 공통되는 문제점이다.

1. TCP/IP 는 도청 가능한 네트워크...

 TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것 만으로도 도청할 수 있다. 따라서 암호화하여 통신해야한다.

보안 방법

1. 통신 자체를 암호화
SSL 또는 TLS라는 다른 프로토콜을 조합함으로써  HTTP의 통신 내용을 암호화할 수 있다.  SSL을 조합한 HTTP를 바로 HTTPS(HTTP over SSL)라고 부른다.

2. 콘텐츠를 암호화
말 그대로 HTTP를 사용해서 운반하는 내용인 HTTP 메세지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.  

2. 통신 상대를 확인하지 않기 때문에 위장이 가능...

HTTP 에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 리퀘스트를 보낼 수 있다. IP 주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다. 이러한 특징은 여러 문제점을 유발한다.

1. 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지를 확인할 수 없다.
2. 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지를 확인할 수 없다.
3. 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
4. 어디에서 누가 리퀘스트 했는지 확인할 수 없다.
5. 의미없는 리퀘스트도 수신한다. —> DoS 공격을 방지할 수 없다.

보완 방법

윗 상자에서 말한 SSL 로 상대를 확인할 수 있다. 
SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누성 등의 위험성이 줄어들게 된다.
한 가지 이점을 더 꼽자면, 클라이언트는 이증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.

3. 완전성을 증명할 수 없기 때문에 변조가 가능하다

여기서 완전성이란 정보의 정확성 을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다. 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부른다.

보완 방법

MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기에는 HTTPS를 사용해야 한다. SSL 에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다.

HTTPS

HTTP에 암호화와 인증과 완전성 보호를 더한 HTTPS

HTTPS는 SSL 의 껍질을 덮어쓴 HTTP 라고 할 수 있다. 즉, HTTPS 는 새로운 애플리케이션 계층의 프로토콜이 아니라는 것이다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜로 대체하는 것 뿐이다. HTTP 는 원래 TCP 와 직접 통신했지만, HTTPS 에서 HTTP 는 SSL 과 통신하고 SSL 이 TCP 와 통신 하게 된다. SSL 을 사용한 HTTPS 는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

HTTPS 의 SSL 에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.

모든 웹 페이지에서 HTTPS를 사용해도 될까?

평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.
하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.

Reference.

• https://jeong-pro.tistory.com/89

TCP와 UDP는 TCP/IP의 전송계층(OSI 7계층 중 4계층, transport)에서 사용되는 프로토콜

네트워크 계층에서 데이터를 수신지 컴퓨터까지 전달했다면, 전송 계층에서는 컴퓨터가 받은 데이터를 애플리케이션까지 전달하는 것이다.

* 전송계층 : 전송에 적합한 크기로 쪼갠 후 목적지의 프로그램을 식별케하는 포트번호를 덧붙이며 IP에 의해 전달되는 패킷의 오류를 검사하고 재전송을 요구하는 등의 제어를 담당하는 계층

TCP와 UDP의 차이

TCP

​

트랜스포트 계층의 TCP 프로토콜은 수신지에 데이터가 정확하게 전달되도록 전송 속도를 조절하거나 도달하지 않은 데이터를 재전송한다. 한마디로, 속도보다는 정확한 전달을 중시

​

UDP

​

VoIP(인터넷 전화)나 동영상 스트리밍 서비스와 같이 실시간 통신이 필요하다면 전송 속도를 중시하는 UDP를 사용한다. TCP와 다르게 정확성보다는 속도를 중시

TCP의 3 way handshacking

TCP는 연결지향 프로토콜로 데이터 송수신 전에 커넥션 연결부터 한다.

커넥션을 맺는 과정에서 3단계로 진행하기 때문에 이것을 3방향 핸드셰이크(3-way handshake)라고 부른다.

커넥션이 맺어지면 데이터를 전송할 수 있는 상태가 되고, 데이터 전송이 끝나면 커넥션을 끊는다.

TCP가 정확하게 데이터를 전달하기 위해

TCP는 데이터 전송에 신뢰성을 더하기 위해 데이터를 세그먼트(segment)라는 단위로 분할하고, 전송속도를 조정하며, 데이터가 제대로 전달되지 않았을 경우 재전송을 하게 된다.

UDP가 신속하게 데이터를 전달하기 위해

통신 과정에서 데이터의 손실이 발생하는데, 일부 손실이 발생해도 문제없는 인터넷전화나 동영상 스트리밍 서비스에서 많이 사용한다.

TCP와 다르게 접속이 맺어졌는지 확인하지 않고(=비연결성) 바로 서버에서 클라이언트로 송신하며 패킷이 도중에 손실되더라도 상관하지 않고 계속 보낸다. 

( UDP의 패킷에 해당하는 데이터그램은 TCP의 세그먼트보다 헤더의 내용이 훨씬 가볍고 간단하다)

UDP에 신뢰성 추가~! ( 복잡해짐.. )

실시간 처리가 필요한 온라인 게임에서는 전송 속도가 우선인 UDP를 사용하긴 하지만, 데이터 전송의 신뢰성 역시 속도에 못지않게 중요하다. 이런 경우에는 애플리케이션 계층에서 흐름 제어(Flow Control)나 혼잡 제어(Congestion control)를 구현하여 부족한 신뢰성을 보완하게 된다.

<참고>

https://m.blog.naver.com/good_ray/221984839492 https://velog.io/@hidaehyunlee/TCP-%EC%99%80-UDP-%EC%9D%98-%EC%B0%A8%EC%9D%B4

HTTP

웹 상에서 클라이언트와 서버 간에 데이터를 주고 받을 수 있는 프로토콜인
HTTP 메소드에는 크게 2가지 방식이 있는데
그것이 GET 방식과 POST 방식

---

GET 

'가져오다'
어떠한 정보를 가져와서 조회하기 위해서 사용되는 방식

• URL에 변수(데이터)를 포함시켜 요청
• 데이터를 header에 포함시켜 전송
• URL에 데이터가 노출되어 보안에 취약
• 캐싱 가능

GET은 URL끝에 ?와 함께 이름과 값으로 쌍을 이루는 요청 파라미터(쿼리 스트링)를 통해 필요한 데이터를 서버로 전송한다. 쿼리 스트링이 여러개일 경우 &로 연결해준다.

불필요한 요청을 제한하기 위해 요청이 캐시될 수 있다.

ex. js, css와 같은 데이터 양이 크고 변경될 일이 적은 정적 컨텐츠

정적 컨텐츠를 요청하고 나면 브라우저에서는 요청을 캐시한다. 동일 요청 발생시 서버로 요청을 보내지 않고 캐시된 데이터를 사용한다.

프론트앤드 개발시 정적 컨텐츠가 캐시되어 컨텐츠를 변경해도 적용되지 않는 경우 브라우저의 캐시를 지워주면 해결된다.

POST

'제출하다'
데이터를 서버로 제출하여 추가 또는 수정하기 위해 사용하는 방식, 작업 수행 시 사용됨

• URL에 변수(데이터)를 노출하지 않고 요청
• 데이터를 body에 포함시켜 전송
• URL에 데이터가 노출되지 않아서 기본 보안이 되어있음
• 캐싱 불가능

GET과 달리 http 메세지의 길이 제한이 없는 body에 담아서 보내기 때문에 대용량 데이터를 전송할 수 있다. 

GET보다는 보안성이 높지만 크롬 개발자 도구나 Fiddler와 같은 툴로 요청 내용 확인이 가능하기 때문에 민감 데이터 전송시에는 반드시 암호화를 해야한다.

POST는 요청 헤더의 content-type에 요청 데이터 타입을 표시해야 한다.

표시하지 않으면 서버는 내용이나 URL에 포함된 리소스 확장자명 등으로 데이터 타입을 유추하고, 알 수 없는 경우엔 aplication/octet-stream로 요청을 처리함

GET과 POST와 멱등성

멱등 - 동일한 연산을 여러 번 수행하더라도 동일한 결과가 나타나는 것

GET은 서버에게 동일한 요청을 여러번 전송하더라도 동일한 응답이 돌아와야하는 멱등성을 갖도록 설계되어있다.

서버의 데이터나 상태를 변경시키지 않아야 멱등성을 갖게 되기 때문에 GET은 주로 조회시 사용되는 것이다.

POST는 서버에게 동일한 요청을 여러 번 전송하더라도 응답은 다 다를 수 있다.

따라서 서버의 상태나 데이터를 변경시킬 때 사용이 된다.

<참고>

https://mangkyu.tistory.com/17 https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/