Network

Proxy Server
- Proxy Server
- Proxy Server의 종류
NAT
OSI 7계층
- 1계층 - 물리계층
- 2계층 - 데이터 링크계층
- 3계층 - 네트워크 계층
- 4계층 - 전송계층
- 5계층 - 세션계층
- 6계층 - 표현계층
- 7계층 - 응용계층
전송계층(Transport Layer)
- TCP와 UDP
- SSL/TLS란?
- SSL/TLS 역사
- SSL/TLS 주요 기능
- SSL/TLS 특징
- SSL/TLS 프로토콜 스택
- SSL/TLS 핸드세이크
- 핸드세이크

Proxy Server

위로

네트워크 프로그램의 일종으로서 클라이언트 기준으로 방화벽을 넘어가서 서버와 클라이언트 간에 인터넷으로 직접 접속을 허용하여 특정 서비스를 중계해주는 역할을 하는 구조물이다.

프록시 서버는 서버에 있는 소켓을 열고, 그 소켓을 통해 인터넷으로의 통신을 허용한다.

예를 들어, 사용자의 컴퓨터가 보호받는 네트워크의 안쪽에 있고, 웹 브라우저를 사용하여 웹 검색을 하고 싶다면 방화벽 상에서 Proxy Server를 설정해야 한다.

클라이언트는 필요한 서비스를 프록시 서버에 요청하고, 서버는 클라이언트의 요청에 따라 외부 네트워크와 연결해주는 서비스 중계 역할을 한다.

클라이언트(자신의 컴퓨터)와 서버(목적지) 사이 데이터를 중계하는 중간 서버 역할!!

보통 어떤 서버에 우회 접속하거나 내 아이피 주소를 숨기면서 인터넷을 사용할 목적으로 많이 이용 하지만 그것 외에 캐시, 방화벽, 보안 등에도 이용한다.
캐시는 접속했던 사이트를 중간에 저장해 두었다가 다시 접속할 때 빠르게 접속/이용할 수 있게 해주는 기능이다.
방화벽이나 보안 기능은 아이피, 포트 ,사이트를 필요 시 차단이나 제한 등 여러가지 설정을 응용하여 보안에 응용할 수 있다.
보통 프록시 서버를 이용하면 평소보다 속도가 훨씬 느려지는데 그것은 우회접속(아이피 숨기기)를 위해 프록시를 사용하는 데 외국 프록시 서버를 이용하기 때문이다.

(프록시 서버의 위치에 따라 속도 차이가 난다!)
자기 아이피 주소를 숨긴다는 말은 프록시 서버를 이용하여 목적지 서버에 접속하면 목적지 서버에 남는 로그에 프록시서버의 주소가 남는다는 것이다. 때문에, 목적지에서는 내가 아닌 프록시 컴퓨터가 접속한 것으로 아는 것!
피시방에서 집에있는 내컴퓨터로 원격접속하여 어떤 사이트에 접속하는 것과 마찬가지다.
프록시서버에는 내가 어떤사이트나 서버에 접속했는지 로그에 남아서 역추적이 가능하다.
프록시 서버를 이용하려면 자신의 pc에 직접 msproxy나 리눅스에 squid 같은 프로그램을 설치하여 서버를 구성하여 이용할 수도 있지만, 공개된 해외 프록시 서버를 이용해도 된다.
요즘 해외 프록시는 프록시 서버 아이피를 알려주는 곳도 있고 바로 프록시를 이용할 수 있는 웹 프록시 사이트도 있다.
프록시 서버에서
- Latency : 반응시간으로 낮을수록 좋고
- Type : Transparent Proxy, Anonymous Proxy, Elite Proxy (T<A<E) 순으로 숨기기 능력이 강력하고 큰 의미는 없다.
- SSL : 보안상 있는 것이 좋다.
- Uptime(가동시간) : 높을수록 좋다

Proxy Server

Proxy는 자신을 통해 다른 네트워크에 간접적으로 접속할 수 있도록 해주는 컴퓨터나 프로그램을 말한다.

즉, 클라이언트의 요청을 중계하는 일을 하는 컴퓨터/프로그램으로 생각하면 될 것이다.

이 때 중계하는 프로그램을 Proxy Program이라 한다. 이러한 프로그램은 서버로서 작동하기 때문에 일반적으로 Proxy Server라고 한다.

Proxy는 요청의 중계라는 추상적 과정을 가르킨다. 때문에 중계의 목적, 중계의 위치, 중계의 방법에 따라 다양한 Proxy Server가 존재한다.

이러한 Proxy Sever의 목적은 아래와 같다.

보안 : 익명의 사용자가 서버에 접근하는 것을 막는다.
속도 : Proxy server는 사용자의 요청을 Cache해서 동일 요청이 들어오면 Cache자원을 반환한다. 이는 서비스의 속도를 높여준다.
ACL : 사이트 접근에 대한 접근 정책을 정의할 수 있다.

(ACL = Proxy Server에 접속할 수 있는 범위를 설정하는 옵션)
Log/Audit : 회사 내 직원의 인터넷 사용을 레포팅할 수 있다. 반대로 인트라넷 사용을 레포팅 할 수도 있다.
지역 네트워크의 제한 우회 : 보안상의 이유로 80포트 외에 포트를 막아 놓는 경우가 있는데, 이러한 제한을 우회하여 원하는 다른 서비스를 이용할 수 있다.

Proxy의 종류

Caching Proxy Server
- 이전 클라이언트의 요청 내용과 응답 컨텐츠를 저장해 두었다가 동일한 요청이 들어오면 저장된 컨텐츠를 전송한다.
- 이 방법을 이용하면 트래픽을 줄이고 성능을 높일 수 있다.
- 비용을 아낄 수 있기 때문에 ISP와 큰 규모의 회사들은 Caching Proxy를 자주 사용한다.
- 널리 사용되고는 있지만 잘못 구현된 Caching Proxy의 구현은 유저 인증에서 문제가 발생하기도 한다.
Web Proxy
- World Wide Web 트래픽에 초점이 맞춰진 Proxy서버를 말한다.
- Web Proxy의 가장 일반적 형태는 Web Cache이다.
- 어떤 Proxy서버는 핸드폰, PDA에 맞게 웹 서버의 컨텐츠를 변환하는 일을 하기도 한다.
Foward Proxy
- 일반적으로 사용되는 Proxy방식이다.
- Proxy 서버는 클라이언트와 애플리케이션 서버 사이에 위치하여 클라이언트가 타겟인 서버에 애플리케이션 서비스를 요청할 때, Proxy서버로 요청을 보내게 된다.
- 그러면 Proxy서버가 타겟인 서버로 요청을 중계하게 된다.
Reverse Proxy
- 기본적 구성은 Forward Proxy와 동일하지만, 클라이언트는 Proxy Server 배후에 있는 타겟서버의 URL이 아닌 Proxy Server의 URL로 요청한다.
- 이를 통해 애플리케이션 서버는 외부로부터 감추어지게 되는 효과를 얻게 된다.

위로

NAT

위로

Network Address Translation

**NAT(네트워크 주소 변환)**은 IP 패킷의 TCP/UDP 포트 숫자와 소스 및 목적지의 IP 주소 등을 재기록하면서 라우터를 통해 네트워크 트래픽을 주고 받는 기술이다.

패킷에 변화가 생기기 때문에 IP나 TCP/UDP의 **체크섬(checksum)**도 다시 계산되어 재기록해야 한다.

그렇기 때문에 네트워크의 성능에 영향을 줄 수밖에 없다!

**NAT**를 쓰는 이유는 여러 대의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위한 경우가 대부분이다. 예를 들어 인터넷 회선을 하나 개통하고 인터넷 공유기를 달아서 여러 PC를 연결하여 사용 하는데, 이것이 가능한 이유가 인터넷 공유기에 **NAT**기능이 탑재되어 있기 때문이다.

중요한 자료가 들어있는 서버를 외부에 공개하지 않게 하기 위해서 중간에 방화벽을 두어 보호한다. 하지만, 방화벽 내부의 컴퓨터는 인터넷에 접속할 수 있도록 해줘야 하기에 방하벽에 NAT를 탑재하여, 외부로 통신 가능하도록 열어준다.

**NAT**를 사용하는 여러가지 이유중 중요한 한가지는, 기업체 등에서 사설 네트워크에속한 여러 개의 호스트가 하나의 공인 IP주소를 사용하여 여러명이 동시에 인터넷에 접속하기 위함이다.

또한, 인터넷의 공인 IP주소를 절약할 수 있고, 인터넷이란 공공망과 연결되는 사용자들의 고유한 사설망을 침입자들로부터 보호할 수 있다는 장점이 있다.

**NAT**를 사용할 때 단점은 여러명이 동시에 인터넷을 접속하게 되므로, 실제로 접속하는 호스트 숫자에 따라서 접속 속도가 느려질 수 있다.

(다만 성능이 좋을수록 대역폭만 줄어들고 체감되는 속도저하는 꽤 적은편!)

**NAT**는 IPv4의 주소 부족 문제를 해결하기 위한 방법으로 고려되었으며, 주로 비공인 네트워크 주소를 사용하는 망에서 외부 공인망(ex. Internet)과의 통신을 위해서 네트워크 주소를 변환하는것이다.

NAT 소프트웨어 : 일반 PC나 서버에서 NAT를 가능하게 하는 소프트웨어들이다.
- Internet Connection Sharing(ICS) : 마소에 기본 포함되어 있으며, NAT + DHCP
- Routing and Remote Access Service
- IPFilter
- ipfirewall
- Netfilter + iptables/nftables
- NPF
- PF
- WinGate

위로

OSI 7계층

위로

네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것.

계층을 나눈 이유는 통신이 일어나는 과정을 단계별로 파악할 수 있기 때문이다.

흐름을 한눈에 알아보기 쉽고, 사람들이 이해하기 쉽고, 7단계 중 특정한 곳에 이상이 생기면 다른 단계의 장비 및 소프트웨어를 건들이지 않고도 이상이 생긴 단계만 고칠 수 있기 때문이다!

그럼 예를 들어서,

PC방에서 오버워치를 하는데 연결이 끊겼다. 어디에 문제가 있는지 확인해보자

1. 모든 PC에 문제가 있다면
라우터의 문제(3계층 네트워크 계층)이거나 광랜을 제공하는 회사의 회선문제(1계층 물리 계층)

2. 한 PC만 문제가 있고 오버워치 소프트웨어에 문제가 있다면(7계층 어플리케이션 계층), 오버워치 소프트웨어에 문제가 없고 스위치게 문제가 있으면(2계층 데이터링크 계층)

이런 식으로 판단하여 다른 계층에 있는 장비나 소프트웨어를 건들이지 않는 것이다.

1계층 - 물리계층

Pysical Layer

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

이 계층에서 사용되는 통신 단위는 비트이며 이것은 1과 0으로 나타내어지는, 즉 전기적으로 ON, OFF 상태라고 생각하면 된다.

이 계층에서는 단지 데이터를 전달만 할 뿐 전송하려는(또는 받으려는) 데이터가 무엇인지, 어떤 에러가 있는지 등에는 전혀 신경 쓰지 않는다.

단지 데이터 전기적인 신호로 변환해서 주고받는 기능만 할 뿐이다. 이 계층에 속하는 대표적인 장비는 통신케이블, 리피터, 허브 등이 있다.

=> 케이블, 리피터, 허브를 통해 데이터를 전송한다.

2계층 - 데이터 링크계층

DataLink Layer

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

따라서 통신에서의 오류도 찾아주고 재전송도 하는 기능을 가지고 있는 것이다.

이 계층에서는 맥 주소를 가지고 통신하게 된다.

이 계층에서 전송되는 단위를 프레임이라고 하고, 대표적인 장비로는 브릿지, 스위치 등이 있다.(여기서 MAC주소를 사용한다)

=> 브릿지나 스위치를 통해 맥주소를 가지고 물리계층에서 받은 정보를 전달함.

데이터 링크 계층(Data link layer)은 포인트 투 포인트(Point to Point) 간 신뢰성 있는 전송을 보장하기 위한 계층으로 CRC기반의 오류 제어와 흐름제어가 필요하다. 네트워크 위의 개체들 간 데이터를 전달하고, 물리 계층에서 발생할 수 있는 오류를 찾아 내고, 수정하는 데 필요한 기능적, 절차적 수단을 제공한다.

주소 값은 물리적으로 할당 받는데 ,이는 네트워크 카드가 만들어질 때부터 맥 주소(MAC address)가 정해져 있다는 뜻이다.

주소 체계는 계층이 없는 단일 구조이다. 데이터 링크 계층의 가장 잘 알려진 예는 이더넷이다.

이 이외에도 HDLC나 ADCCP 같은 포인트 투 포인트(point-to-point) 프로토콜이나 패킷 스위칭 네트워크나 LLC, ALOHA 같은 근거리 네트워크용 프로토콜이 있다.

네트워크 브릿지나 스위치 등이 이 계층에서 동작하며, 직접 이어진 곳에만 연결할 수 있다.

=> 프레임에 주소 부여(MAC - 물리적 주소), 에러검출/재전송/흐름제어

3계층 - 네트워크계층

Network Layer

이 계층에서 가장 중요한 기능은 **데이터를 목적지까지 가장 안전하고 빠르게 전다랗는 기능(라우팅)**이다.

여기에 사용되는 프로토콜의 종류도 다양하고, 라우팅하는 기술도 다양하다

이 계층은 경로를 선택하고 주소를 정하고 경로에 따라 패킷을 전달해주는 것이 이 계층의 역할이다.

이 계층의 대표적인 장비는 라우터이며, 요즘은 2계층의 장비 중 스위치라는 장비에 라우팅 기능을 장착한 Layer 3 스위치도 있다.(여기서 IP주소를 사용한다.)

네트워크 계층(Network Layer)은 여러개의 노드를 거칠 때마다 경로를 찾아주는 역할을 하는 계층으로 다양한 길이의 데이터를 네트워크들을 통해 전달하고, 그 과정에서 전송 계층이 요구하는 서비스 품질(QoS)을 제공하기 위한 기능적, 절차적 수단을 제공한다.

네트워크 계층은 라우팅, 흐름제어, 세그멘테이션(segmentation/desegmentation), 오류 제어, 인터네트워킹(Internetworking) 등을 수행한다.

라우터가 이 계층에서 동작하고 이 계층에서 동작하는 스위치도 있다.

데이터를 연결하는 다른 네트워크를 통해 전달함으로써 인터넷이 가능하게 만드는 계층이다.

논리적인 주소 구조(IP), 곧 네트워크 관리자가 직접 주소를 할당하는 구조를 가지며 계층적(Hierarchical)이다.

서브네트의 최상위 계층으로 경로를 설정하고, 청구 정보를 관리한다. 개방형 시스템들의 사이에서 네트워크 연결을 설정, 유지, 해제하는 기능을 부여하고, 전송 계층 사이에 네트워크 서비스 데이터 유닛(NSDU : Network Service Data Unit)을 교환하는 기능을 제공한다.

=> 주소부여(IP), 경로설정(Route)

- IP 계층

TCP/IP 상에서 IP 계층이란 네트워크의 주소(IP 주소)를 정의하고 IP패킷의 전달 및 라우팅을 담당하는 계층

OSI 7계층 모델의 관점에서 보면 IP계층은 네트워크 계층에 해당. 즉, 패킷을 목적지까지 전달하는 역할 및 그에 수반되는 기타 역할을 함

IP 계층의 주요 역할
- IP 계층에서는 그 하위 계층인 데이터 링크 계층의 하드웨어적인 특성에(즉, ATM 이든 Frame Relay든 상관없이) 관계없이 독립적인 역할을 수행
IP 계층 상에 있는 주요 프로토콜
- 패킷의 전달을 책임지는 IP
- 패킷 전달 에러의 보고 및 진단을 위한 ICMP
- 복잡한 네트워크에서 인터네트워킹을 위한 경로를 찾게해주는 라우팅 프로토콜

- IP 프로토콜

TCP/IP 기반의 인터넷 망을 통하여 데이터그럼의 전달을 담당하는 프로토콜

주요 기능
- IP 계층에서 IP 패킷의 라우팅 대상이 됨(Routing)
- IP 주소 지정(Addressing)
주요 특징
- '신뢰성(에러제어)' 및 '흐름 제어' 기능이 전혀 없음 -> Best-Effort Service
  
  신뢰성을 확보하려면 IP 계층 위의 TCP와 같은 상위 트랜스포트 계층에 의존
- 비연결성 데이터그램 방식으로 전달되는 프로토콜 -> Connectionless
- 패킷의 완전한 전달(소실, 중복, 지연, 순서바뀜 등이 없게함)을 보장 않음 -> Unreliable
- IP 패킷 헤더 내 수신 및 발신 주소를 포함 -> IPv4 헤더, IPv6 헤더, IP주소
- IP 헤더 내 바이트 전달 순서 : 최상위 바이트 (MSB)를 먼저 보냄 -> Big-endian
- 경우에 따라 단편화가 필요하다
- TCP, UDP, ICMP, IGMP 등이 IP 데이타그램에 실려서 전송

4계층 - 전송계층

Transport Layer

통신을 활성화하기 위한 계층이다. 보통 TCP프로토콜을 이용하며, 포트를 열어서 응용프로그램들이 전송을 할 수 있게 한다.

만약 데이터가 왔다면 4계층에서 해당 데이터를 하나로 합쳐서 5계층에 던져준다.

단대단 오류제어 및 흐름제어 이 계층 까지는 물리적인 계층에 속한다.(TCP/UDP 프로토콜을 사용한다)

전송계층(Transport layer)은 양 끝단(End to End)의 사용자들이 신뢰성있는 데이터를 주고 받을 수 있도록 해 주어, 상위 계층들이 데이터 전달의 유효성이나 효율성을 생각하지 않도록 해준다.

시퀀스 넘버 기반의 오류 제어 방식을 사용한다.

전송계층은 특정 연결의 유효성을 제어하고, 일부 프로토콜은 상태 개념이 있고(stateful), **연결 기반(connection oriented)**이다.

이는 전송 계층이 패킷들의 전송이 유효한지 확인하고 전송 실패한 패큿들을 다시 전송한다는 것을 뜻한다.

가장 잘 알려진 전송 계층의 예는 TCP이다.

종단간(end-to-end) 통신을 다루는 최하위 계층으로 종단간 신뢰성 있고 효율적인 데이터를 전송하며, 기능은 오류검출 및 복구와 흐름제어, 중복검사 등을 수행한다.

=> 패킷 생성(Assembly/Sequencing/Deassembly/Error detection/Request repeat/Flow control) 및 전송

- TCP 프로토콜

Transmission Control Protocl

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

양종당 호스트 내 프로세스 상호 간에 신뢰적인 연결지향성 서비스를 제공
- IP의 비신뢰적인 최선형 서비스에다가 신뢰적인 연결지향성 서비스를 제공하게 됨
  
  신뢰적인 전송을 보장함으로써, 어플리케이션 구현이 한층 쉬워지게 됨

신뢰성 있음(Reliable)

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

TCP 하위 계층인 IP 계층의 신뢰성 없는 서비스에 대해 다방면으로 신뢰성을 제공
연결지향적(Connection-oriented) -> TCP 연결
- 같은 전송계층의 UDP가 비연결성(connectionless)인 것과는 달리, TCP는 연결지향적 임
- 이 경우, 느슨한 연결(Loosly Connected)을 갖으므로 강한 연결을 의미하는 가상회선이라는 표현보다는 오히려 연결지향적이라고 말한다.
- 연결 관리를 위한 연결설정 및 연결해제가 필요 -> TCP연결설정, TCP연결종료
- 양단간 어플리케이션/프로세스는 TCP가 제공하는 연결성 회선을 통하여 서로 통신

- UDP 프로토콜

User Datagram Protocol

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

신뢰성이 낮은 프로토콜로써 완전성을 보증하지 않으나,
가상회선을 굳이 확립할 필요가 없고 유연하며 효율적 응용의 데이터 전송에 사용

비연결성이고, 신뢰성이 없으며, 순서화되지 않은 Datagram 서비스 제공
- 메시지가 제대로 도착했는지 확인하지 않음 (확인응답 없음)
- 수신된 메세지의 순서를 맞추지 않음 (순서제어 없음)
- 흐름제어를 위한 피드백을 제공하지 않음 (흐름제어 없음)
- 검사합을 제외한 특별한 오류 검출 및 제어 없음 (오류제어 거의 없음).
  
  UDP를 사용하는 프로그램 쪽에서 오류제어 기능을 스스로 갖춰야함
- 데이터그램 지향의 전송계층용 프로토콜(논리적인 가상회선 연결이 필요없음)
  
  비연결접속상태 하에서 통신
실시간 응용 및 멀티태스킹 가능
- 빠른 요청과 응답이 필요한 실시간 응용에 적합
- 여러 다수 지점에 전송 가능 (1:多)
헤더가 단순함
- UDP는 TCP처럼 16비트의 포트 번호를 사용하나,
- 헤더는 고정크기의 8비트 (TCP는 20바이트) 만 사용
  
  즉, 헤더 처리에 많은 시간과 노력을 요하지 않음

5계층 - 세션계층

Session Layer

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

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

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

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

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

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

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

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

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

6계층 - 표현계층

Presentation Layer

데이터 표현이 상이한 응용 프로세스의 독립성을 제공하고, 암호화 한다

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

MIME 인코딩이나 암호화 등의 동작이 이 계층에서 이루어진다.

예를 들면, EBCDIC로 인코딩된 문서 파일을 ASCII로 인코딩된 파일로 바꿔 주는 것, 해당 데이터가 TEXT인지, 그림인지, GIF인지, JPG인지의 구분 등이 표현계층의 몫이다.

=> 사용자의 명령어를 완성 및 결과 표현. 포장/압축/암호화

7계층 - 응용계층

Application Layer

최종 목적지로서 HTTP, FTP, SMTP, POP3, IMAP, Telnet 등과 같은 프로토콜이 있다.

해당 통신 패큿들은 방금 나열한 프로토콜에 의해 모두 처리되며 우리가 사용하는 브라우저나, 메일 프로그램은 프로토콜을 보다 쉽게 사용하게 해주는 응용프로그램이다.

한마디로 모든 통신의 양 끝단은 HTTP와 같은 프로토콜이지 응용프로그램이 아니다.

응용계층(Application Layer)은 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.

일반적인 응용서비스는 관련된 응용 프로세스들 사이의 전환을 제공한다.

응용 서비스의 예로, 가상 터미널(예를 들어, 텔넷), "Job transfer and Manipulation protocol"(JTM, 표준 ISO/IEC 8832) 등이 있다.

=> 네트워크 소프트웨어 UI부분, 사용자의 입출력(I/O) 부분

- HTTP 프로토콜

HypterText Transfer Protocol

웹 상에서 웹 서버 및 웹브라우저 상호 간의 데이터 전송을 위한 응용계층 프로토콜

처음에는, WWW 상의 하이퍼텍스트형태의 문서를 전달하는 데 주로 이용

현재는, 이미지, 비디오, 음성 등 거의 모든 형식의 데이터 전송 가능

요청 및 응답의 구조
- 동작 형태가 클라이언트/서버 모델로 동작
메세지 교환 형태의 프로토콜
- 클라이언트와 서버간에 'HTTP 메세지'를 주고받으며 통신(SMTP 전자메일 프로토콜과 유사)
- HTTP의 응답 및 요청 메세지 구성
- HTTP 메세지 내 헤더 항목들
트랜잭션 중심의 비연결성 프로토콜
- 종단간 연결이 없음 (Connectionless)
- 이전의 상태를 유지하지 않음 (Stateless)
전송계층 프로토콜 및 사용 포트 번호
- 전송계층 프로토콜 : TCP
- 사용 포트 번호 : 80번
http 표준
- HTTP 1.0 : RFC 1945 (~1997년)
  - 유용한 초기 개념들 도입
  - HTTP 헤더, HTTP 메서드, HTTP 응답 코드, 리다이렉트, 비지속 연결 등
- HTTP 1.1 : RFC 2068 -> RFC 2616 -> RFC7230~7235 (1998년)
  - HTTP 1.0으로부터 기능 향상
  - HTTP 헤더 내 Host 필드를 필수 항목으로 함 (1개 IP 주소에 다수의 가상 호스팅 가능)
  - HTTP 헤더 내 Accept 필드에 의한 컨텐츠 협상
  - 잘 정의된 캐시 컨트롤
  - 블록 단위 인코딩 전송
  - 지속 연결 회선(킵얼라이브 커넥션)을 통한 재사용 가능
  - 요청 파이프라인을 이용한 병렬 커넥션 처리(실제 사용 거의 없음) 등

위로

전송계층(Transport Layer)

위로

먼저 네트워크란 데이터를 교환하기 위해 전송 매체를 매개로 서로 연결되어 있는 것이고 인터넷은 전세계 컴퓨터들이 서로 연결되어있는 거대한 네트워크를 뜻한다.

사람간의 대화에서 같은 언어를 이용해 의사소통 하듯 네트워크 상에서 데이터를 주고받기 위해서 일종의 정해진 규약이 있는데 이것을 프로토콜이라고 부른다.

네트워크 상에서 정보를 주고받으려면 어느 경로로 보낼지 어떤 방식으로 데이터를 보낼지 등등 고려해야할 사항이 많다. 만약 하나의 규약을 정해놓았다면 문제가 발생 하였을시 전체를 바꾸어야 하고 또 문제가 발생하기도 쉬울 것이다. 그래서 역할을 나누어 네트워크는 네트워크 계층 구조를 가지게 되었다. 각각의 계층은 모듈단위로 독립적이지만 서로 상호 유기적인 관계를 가진다.

TCP/IP 계층을 보면 크게 4개로 나누어져 있고 각각의 계층마다 하는 역할이 다르고 각각의 여러 프로토콜이 존재한다. 이것을 다 알아보는거는 주제에 벗어나는 것 같으므로 TCP가 속해있는 Transport Layer 즉 전송 계층만 간단히 설명하자면

두 호스트 간에 연결을 맺고 최종적인 통신 목적지까지 데이터를 전달하는 기능을 한다.

✒️ TCP 와 UDP

전송 계층에는 크게 TCP(Transmission Control Protocol) 와 UDP(User Datagram Protocol) 2가지 프로토콜이 있다.

-TCP 연결지향적이며 오류제어, 흐름제어, 혼잡제어, 타이머재전송 등의 기능을 하며 연결지향이란말은 데이타를 전송하는 측과 데이타를 전송받는 측에서 전용의 데이타 전송 선로(Session)을 만든다는 의미이다. 데이타의 신뢰도가 중요하다고 판단될때 주로 사용된다.(가상회선 방식 패킷교환)

-UDP 비연결지향이며, 최소한의 오류제어 기능만 수행한다. 단순히 데이타를 받거나, 던져주기만 하는 프로토콜이다. UDP는 특히 실시간 멀티미디어 정보를 처리하기 위해서 주로 사용한다.(데이터그램 방식 패킷교환)

여기서 딱 보이는 둘의 차이는 연결 비연결이 보인다.

서두가 길었다. TCP에서 연결지향적인 특성을 갖게 해주는 과정, 방법이 바로 3 Way-Handshake 방식으로 잠시 뒤에 알아보겠다.

✒️ SSL/TLS란?

Secure Socket Layer, Transport Layer Security

전송 계층 상에서 클라이언트, 서버에 대한 인증 및 데이터 암호화 수행
- 클라이언트와 서버 양단 간 응용계층 및 TCP 전송계층 사이에서 안전한 보안 채널을 형성해 주는 역할을 수행하는 보안용 프로토콜
주요 응용
- HTTP(HTTPS), FTP(FTPS), TELEMENT, SMTP, SIP, POP, IMAP 등에서 사용 가능
- 주로, 웹 브라우저와 웹 서버사이의 안전한 보안 채널을 제공하기 위해 많이 사용된다

OpenSSL

DTLS는 TLS프로토콜은 UDP에 적용가능하게 해주는 UDP를 위한 프로토콜이다. 그러므로 UDP기반의 애플리케이션들은 이 DTLS를 사용함으로 도청, 간섭, 메시지 변조 등 네트워크 상에서 발생할 수 있는 공격들을 막을 수 있다. 특히나 UDP를 사용하는 IoT에 보안성을 추가해줄 수 있는 프로토콜로 제시되고 있다.

✒️ SSL/TLS 역사

최초 제안 : 넷스케이프 사
- 버젼 : SSL v1.0(1994.7), SSL v2.0(1994.12), SSL v3.0(1996.11)
  
  SSL v3.0은 그 당시 사실상의 웹 보안 표준이었음
SSL의 표준화 기여 => TLS 표준 - SSL v3.0 을 참고로하여 RFC 2246(1999년)으로 표준화된 것이 TLS 임 - 버젼 : TLS 1.0 (RFC 2246,1999) : SSL v3.1에 해당, TLS 1.1 (RFC 4346, 2006), TLS 1.2 (RFC 5246, 2008)

따라서, SSL 및 TLS는 본질적으로 같으며 버전이 다른 정도임

✒️ SSL/TLS 주요 기능

상호 인증
- 공개키 인증서를 이용하여 서버, 클라이언트의 상호 인증
- 즉, 클라이언트/서버 두 응용 간에 상대방에 대한 인증
메세지 압축
- 디폴트는 Null(즉, 무 압축)
  
  압축 알고리즘은 미리 정해지지 않고 협상으로 지정 가능
메세지 인증(메세지 무결성)
- 메세지 인증 코드 HMAC에 의한 메세지 무결성 제공(HMAC MD5, HMAC SHA-1 등)
암호화용 세션 키 생성(대칭 키 합의)을 위한 키 교환
- RSA : 두 키(공개 키 및 개인 키)가 하나의 수 체계를 형성(서버 공개 키 사용)
- Diffie-Hellman : Diffie-Hellman프로토콜을 기반으로 한 키 교환 방식
생성된 공유 비밀키에 의해 암호화된 종당간 안전한 연결 통로 제공
- 스트링 암호화 : 40, 128 비트의 RC4
- 블록 암호화 : IDEA, 40, 56비트의 DES, 168 비트의 3DES 등

✒️ SSL/TLS 특징

클라리언트/서버 기반의 프로토콜
응용 프로그램(어플리케이션) 자체 구현 가능
- 대부분의 다른 보안 프로토콜(EAP,IPsec 등)은 운영체제 등에 밀접하게 관련됨
인증 구조 : X.509
- X.509에서 규정된 공개키 인증서 교환에 의해 상대방에 대한 인증 수행
키 교환 방식 : (협상 선택 가능)
- Null, RSA 공개 키 교환, Anonymous Diffie-Hellman 키 교환, Ephermeral Diffie-Hellman 키 교환, Fixed Diffie-Hellman 키 교환, Fortezza
대칭키 암호화 방식 : (협상 선택 가능)
- RC2 (40), RC4 (40), RC4 (128), DES, Triple DES, IDEA 등
해쉬 알고리즘 : (협상 선택 가능)
- Null, MD5, SHA-1

✒️ SSL/TLS 프로토콜 스택

전송계층 TCP 위에서, 보안 소켓/보안 채널/터널링을 구성
- 응용계층에서 생성된 데이터에 대한 보안(인증,무결성,기밀성),압축 등의 서비스 제공
- SSL/TLS 보안 터널을 위한 TCP/UDP 포트번호
  
  ex) 보안 HTTP를 위한 포트번호 4433 ( HTPS )
- 한편, UDP 상에서도 가능한 버전으로
  - DTLS (Datagram Transport Layer Security) RFC 6347(2012년)가 있음
SSL/TLS의 상세 프로토콜 스택 : ☞ SSL/TLS 구성 프로토콜 참조

=> 크게, 하위 레코드 계층 프로토콜(단편화,압축,무결성,암호화,인증 기능 제공)과 위 핸드세이크 관련 프로토콜들로 구성*

✒️ SSL/TLC 핸드세이크

초기 협상 단계 => 인증 단계 => 보안 채널 형성 => 상호 암호화 통신 시작

초기 협상 단계
- 클라이언트, 서버 간에 Client Hello, Server Hello 메세지 교환
- 클라이언트가 서버에게 Cipher Suite(사용 가능 암호화, 해싱 방식 등)을 보내고 서버 인증서를 요구
인증단계
- 서버에서 공개키, 서버명, 인증기관 주소 등을 포함한 인증서를 클라이언트에게 전송
- 이 때, 서버는 클라이언트가 제시한 것 중 자신이 선택한 암호화 방식 및 인증서를 보냄
- 필요히 클라이언트는, 인증서를 발급한 인증기관 서버에 접속하여 서버 인증서의 유효성 확인
보안채널 형성
- 클라이언트는 보안 채널 형성에 필요한 세션키를 만들기 위해,
- 서버의 공개키를 이용하여 임의의 수(Pre Master Key)를 암호화시켜 서버에게 전송하고,
- 서버는 **자신의 비밀키(개인키)**로 이를 해독(역암호화)하게 됨
- 이때 임의의 수(Pre Master Key)로부터 Master Key를 유도하고,
- 이 Master Key로부터 양측은 암호화,복호화에 필요한 세션키를 생성함
상호 암호화 통신 시작
- 즉, 보안성이 확립된 TLS 터널 내에서 상호 통신

✒️ 핸드세이크(Handshake)

통신의 양측 간에 조건에 합의해 가는 정보 교환 과정

- DTE, DCE

DTE : Data Terminal Equipment

DCE : Data Communications Equipment

DTE
- 사용자 - 네트워크 인터페이스의 사용자측에서 데이터발신 장치나 수신 장치, 또는 두 가지 겸용으로 사용되는 장치
- DTE는 반드시 모뎀과 같은 DCE 장치를 통해 데이터 네트워크에 연결되며, 일반적으로 DCE에 의해 생성된 클럭처리 신호를 말한다.
- DTE에는 컴퓨터, 멀티플렉서, 라우터 등과 같은 장치가 포함된다.
DCE
- 사용자 - 네트워크 인터페이스의 네트워크 측으로 구성되는 통신 네트워크 장비의 연결 수단
- DCE는 네트워크로 연결되는 물리적 수단이며, 트래픽을 전송하고, DCE장치와 DTE장치 사이에서 데이터 전송을 동기화 시키는 데 사용되는 클럭신호를 제공
- DCE에는 모뎀과 인터페이스 카드가 포함된다.

DTE - DCE 간의 데이터 흐름을 제어하기 위한 핸드세이킹!!

- TCP 3-way Handshaking

TCP/IP 프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정

간단하게 비유를 들어 설명하자면 a가 b에게

1. b야 내말 잘 들리니? b가 a에게

2. 응 잘들려 a야 너도 내말 잘 들리니?

3. 응 잘들려!

과 같은 방법으로 서로 의사소통이 할 환경이 잘 구성 되었는지, 즉 연결이 잘 되었는지 확인하는 과정이다. 네트워크 상에서는 서로 패킷을 주고받아 위 과정을 수행한다.

Client > Server : TCP SYN
Server > Client : TCP SYN ACK
Client > Server : TCP ACK

여기서 SYN는 synchronize sequence numbers, 그리고 ACK는 acknowledgment의 약자

< 역할 >

양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하고, 실제로 데이터 전달이 시작하기 전에 한쪽이 다른 쪽이 준비되었다는 것을 알 수 있도록 한다.
양쪽 모두 상대편에 대한 초기 순차일련번호를 얻을 수 있도록 한다.

< 과정 >

A클라이언트는 B서버에 접속을 요청하는 SYN 패킷을 보낸다. 이때 A클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는SYN_SENT 상태가 되는 것이다.
B서버는 SYN요청을 받고 A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하기를 기다린다. 이때 B서버는 SYN_RECEIVED 상태가 된다.
A클라이언트는 B서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오가게 되는것이다. 이때의 B서버 상태가 ESTABLISHED 이다.

위와 같은 방식으로 통신하는것이 신뢰성 있는 연결을 맺어 준다는 TCP의 3 Way handshake 방식이다.

위 방식을 통해 TCP는 연결지향적인 특성과 자체적으로 오류를 처리하며 순서가 뒤바뀐 패킷을 교정해주는 기능이 더불어 주로 데이터의 신뢰도가 중요하다고 판단되어질 때 쓰인다.

신뢰도 확보가 중요하거나 용량이 큰 데이터를 전달해야 때, 실시간일 필요는 없을 때 활용 된다.

하지만 데이터의 신뢰성 보다 전송 속도가 중요시되는 경우면 어떨까? 스트리밍 서비스 같은 경우 속도가 생명이다. 만약 계속해서 버퍼링이 걸린다면 사용자는 매우 불쾌할 것이다.

앞서 말한 UDP 프로토콜은 위와 같은 과정이 없이 단순히 데이터만을 전송하므로 속도가 빠르다. 스트리밍 서비스 같은경우 약간의 화질이나 음질의 손상이 있다 해도 끊기지 않는 서비스가 중요하다. 그래서 **UDP**방식을 사용한다.

*추가로 이러한 3-way handshakinig의 취약점을 이용해 서버를 공격하는 방법이 바로 **SYN Flodding*이라고 한다.

3way handshaking 과정중 서버는 2단계 에서 (클라이언트로 부터 요청을받고 응답을 하고난후 다시 클라이언트의 응답을 기다리는 상태)  이 연결을 메모리 공간인 백로그큐(Backlog  Queue) 에 저장을 하고 클라이언트의 응답 즉 3단계를 기다리게 되고 일정 시간 (default 로 UNIX/LINUX : 60초 , Windows : 256초 , Apache : 300 초이며 수정 가능) 동안 응답이 안오면 연결을 초기화한다.

바로 이 점을 이용한 공격법이다.

악의적인 공격자가 실제로 존재하지 않는 클라이언트IP로 응답이 없는 연결을 초기화 하기전에 또 새로운 연결 즉 1단계 요청만 무수히 많이 보내어 백로그 큐를 포화 상태로 만들어 다른 사용자로 부터 더이상에 연결 요청을 못 받게 하는 공격 방법이다.

대응책으로는 연결 타이머 시간을 짧게 하거나 백로그 큐 사이즈를 늘리는법, 정해진 시간동안 들어오는 연결 요구의 수를 제한하는법, 쿠키(cookie)라는 것을 이용해서 전체 연결이 설정되기 전까지는 자원의 할당을 연기하는 법이 있다..

- 무선 LAN보안 을 위한 4-way Handkshaking

3-way handshake는 TCP 연결을 초기화할 때 사용한다면, 4-way handshake는 세션을 종료하기 위해 수행되는 절차이다.

< 역할 >

비록 양단간에 사전에 준비된 키가 없더라도 안전하지 못한 채널(비 보안 채널)을 통해서도 같은 **비밀 키(세션 키)**를 공유할 수 있게끔 일련의 패킷등을 교환해가며 대칭 키를 합의하는 과정

< 과정 >

클라이언트가 연결을 종료하겠다는 FIN플래그를 전송한다. 서버가 FIN플래그로 응답하기 전까지 연결을 계속 유지한다.
서버는 일단 확인메시지를 보내고 자신의 통신이 끝날때까지 기다리는데 이 상태가 TIME_WAIT상태다. 수신자는 ACK Number 필드를 Sequence Num+1로 지정하고 ACK플래그 비트를 1로 설정한 세그먼트를 전송한다. 그리고 자신이 전송할 데이터가 남아있다면 이어서 계속 전송한다.
서버가 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN플래그를 전송한다.
클라이언트는 확인했다는 메시지를 보낸다.

그런데 만약 Server에서 FIN을 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN패킷보다 늦게 도착하는 상황"이 발생한다면 어떻게 될까요?

Client에서 세션을 종료시킨 후 뒤늦게 도착하는 패킷이 있다면 이 패킷은 Drop되고 데이터는 유실될 것입니다. 이러한 현상에 대비하여 Client는 Server로부터 FIN을 수신하더라도 일정시간(디폴트 240초) 동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거치게 되는데 이 과정을 TIME_WAIT 라고 합니다.

위로

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Network

Proxy Server

Proxy Server

Proxy의 종류

NAT

OSI 7계층

1계층 - 물리계층

2계층 - 데이터 링크계층