네트워크 프로토콜 스택

네트워크를 구성하고 인터넷을 통해 전송하기 위한 패킷을 구성하고 전송 또는 수신하기 위한 과정을 O/S 내부에 스택(stack) 구조로 단계적으로 구성된 네트워크 S/W 집합

전달할 데이터 생성 시 프로토콜 스택에 따라 구성하는 작업이 필요하다.

1. 스택 (stack)

• 쌓아놓는 구조

• LIFO(Last In First Out, 후입선출) 구조

2. TCP/IP

2.1. TCP/IP (Transmission Control Protocol/Internet Protocol)

• 현재 인터넷을 사용하는 네트워크에서 기본으로 사용하는 네트워크 프로토콜 스택

• Windows, Linux, Mac OS에는 TCP/IP를 포함하고 있다.

• TCP/IP는 4계층 구조를 가지고 있다.

• 참고
  https://ko.wikipedia.org/wiki/%EC%9D%B8%ED%84%B0%EB%84%B7_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C_%EC%8A%A4%EC%9C%84%ED%8A%B8

프로그래밍 시 네트워크 프로토콜 스택을 사용할 수 있는 함수가 있다.
네트워크 프로그램에서 상대편 호스트와 연결할 때는 네트워크 프로토콜 스택을 사용한다.

2.2 TCP/IP 계층 구조 (4 계층)

스택이니 구조가 쌓여있는 형태이다.
가장 윗쪽은 애플리케이션, 아랫쪽은 NIC로 되어 있다.

○ Application Layer

가장 상단에 위치한 레이어다.
전송 시 데이터를 어떤 프로토콜로 보낼지 설정한다.

• Application에서 통신을 수행할 때 적용할 protocol로 구성

• 대표적 프로토콜

1. HTTP/HTTPs
   Web을 사용(Web browser)하기 위한 기본 프로토콜

2. SSH
   보안이 적용된 원격 shell 접속을 위한 프로토콜 (명령 프롬포트)

3. FTP
   원격 파일 전송을 위한 프로토콜

4. SMTP
   메일 전송을 위한 프로토콜

5. POP3
   메일 수신을 위한 프로토콜

• 사용자 프로토콜
  소켓(socket) 기반 프로그램 작성시 직접 설계 적용

위 내용은 표준 프로토콜에 대한 설명이며, 만약 새로운 네트워크 프로토콜을 만들고 싶다면 네트워크 프로토콜 설계를 해야 한다.

애플리케이션 레이어 계층을 통과할 때, 사용할 프로토콜에 맞게 데이터를 구성하게 된다.
프로토콜은 기본적으로 헤더와 바디가 있다.
헤더에는 기본 공통적인 정보가 있고, 바디에는 실질적인 데이터가 포함되어 있다.
그러면 첫 번째 패킷 구조를 생성하게 되고, 이렇게 통과한 뒤 다음 계층으로 넘어간다.

○ Transport Layer

• port 번호 결정

• 프로토콜

전송하려는 Port 번호를 결정한다.
상대방이 80번을 사용하면 80번으로 설정하고,
내가 8000번을 사용하면 상대편이 8000번이 된다.

Port 번호를 설정하며 어떤 방식으로 보낼건지 결정된다.

- TCP (Transmission Control Protocol)

1. 1:1 통신, 항상 연결 상태 유지
   HTTP 프로토콜을 TCP 기반 프로토콜이지만 연결 상태를 항상 유지하지 않는다.

2. 패킷을 전송하고 응답이 없으면 다시 패킷을 전송한다.

3. 통상 3번의 패킷 교환을 통해 하나의 패킷전송을 완료

4. 패킷 전송 신뢰성이 높지만 속도가 느리다.

TCP는 항상 1대1 통신만을 수행하며, 다대다를 지원하지 않는다.
일반적인 전화통화와 유사하다고 생각하면 된다.
간혹 예외는 있지만, 기본적으로 항상 연결 상태를 유지한다.

TCP의 장점은 데이터를 안정적으로 정확하게 전달할 수 있다는 것이다.
Three-End Shaking이라는 방식으로 통신을 하기 때문이다.

1. 클라이언트가 서버에 연결 요청(SYN 패킷)을 보내기
2. 서버가 이를 받고, 응답(SYN-ACK 패킷)을 보내기
3. 클라이언트가 다시 확인(ACK 패킷)을 보내며 연결이 성립

한 번의 패킷을 보내면 2개가 오는, 3단계 핸드셰이크가 사용된다.
이렇게 쓰리엔드 쉐이킹이 일어남으로 중간에 데이터가 유실되지 않고 확실하게 전달한다는 안전성이 생긴다.
만약, 중간에 데이터가 유실되더라도 상대방이 패킷을 받지 못 했다는 확인 패킷이 온다.

대신, 이러한 방법은 속도가 느릴 수 밖에 없다.
패킷 자체가 안정적으로 잘 보내진다는 보장이 있고 신뢰성은 높지만 속도가 느리다는 것이다.

TCP는 1대1을 유지하는데, HTTP는 TCP 위에서 동작하는 프로토콜이지만, 연결 상태를 항상 유지하지 않는다(비연결성).
연결 트래픽 관리를 위해서다.

HTTP는 웹에서 정보를 주고받기 위한 애플리케이션 레벨의 프로토콜이며, 비연결성(stateless)다.
HTTP는 TCP 위에서 동작한다. 웹 브라우저는 TCP를 통해 서버와 연결한 후 HTTP 요청을 보낸다.
하지만, 요청이 끝나면 연결 트래픽 관리를 위해서 TCP 연결이 종료되기 때문에 비연결성을 띈다.

쇼핑몰 같은 웹사이트에서 로그인 후 로그인 상태를 유지하는 건 HTTP의 비연결성을 고려한 세션 관리 방식 때문이다.
HTTP 자체는 비연결 성이지만, 세션과 쿠키 등의 개념을 사용해 로그인 상태를 유지한다.

- UDP (User Datagram Protocol)

1. 1:1, 1:N(boradcast), M:N(multicast) 통신

2. TCP와 다르게 UDP는 패킷을 전송만 하고 수신 확인은 하지 않는다.

3. 신뢰성은 떨어지나 전송 속도가 빠르다.

4. 스트리밍 서비스

TCP와 차이점
TCP는 상대와 연결을 유지해야 하고 1:1이기 때문에 데이터를 보내면 패킷이 3번 발생하지만,
UDP는 그런 과정 없이 패킷 생성 후 연결하여 UDP로 보내면 끝이다. 즉, 확인 과정이 없다(비연결성).
UDP는 단순히 데이터를 보내고 끝내기 때문에 실시간 스트리밍에서 많이 사용된다.

만약, 서버 쪽에서 데이터 생성 후 클라이언트로 전송할 때 TCP로 전송 시 1:1 밖에 허용이 안 되지만,
UDP는 다양하게 가능하기 때문에 1:N 서비스로 많이 사용된다(스트리멍 서비스).
즉, 데이터 전송이 잘 됐는지 신경쓰지 않고 한 명이 여러 명에게 데이터를 쫙 쏜다고 생각하면 된다.

영상이 60프레임일 때 1-2개 이미지가 조금 소실된다고 해도 동영상이 아예 없어지는 것이 아닌 것과 같이 UDP는 연결 상황이 별로 중요하지 않다.
신뢰성이 필요 없이 데이터 전송을 빨리해야 할 때 사용된다.
그리고 대량의 데이터를 보낼 때도 속도가 빠르게 때문에 좋다.

프로그래밍 관점, 송수신 관저에서만 보면 TCP에 비해 UDP 데이터 전송이 쉽지만,
연결을 유지하지 않기 때문에 이것을 보완하기 위해서는 프로그래밍이 더 필요하다.

즉, 데이터를 정확하게 주고 받는 것은 TCP
다량의 데이터를 빠르게 주고 받는 것은 UDP다.

○ Internet Layer

• IP Address 결정

• 프로토콜

1. IP (Internet Protocol)
   https://ko.wikipedia.org/wiki/%EC%9D%B8%ED%84%B0%EB%84%B7_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

2. ICMP
   ping 프로그램이 사용
   https://ko.wikipedia.org/wiki/%EC%9D%B8%ED%84%B0%EB%84%B7_%EC%A0%9C%EC%96%B4_%EB%A9%94%EC%8B%9C%EC%A7%80_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

○ Network Access Layer

• 실제 패킷 전송 / 수신

• NIC(Network Interface Card) 를 통하여 실제 물리적인 네트워크에 패킷 전송

• NIC에는 NIC 식별 MAC Address가 부여

데이터를 송신하기 위해 어플리케이션으로 전송을 한다고 가정하면
헤더 HTTP가 있거나 우리가 생성한 프로토콜이 있을 것이다.
그렇게 응용 계층에서 데이터를 구성하고 구성된 내용이 전송 계층으로 간다.
이 전송 계층에서 port 번호가 추가되고 전송 방식이 TCP일지 UDP일지 정해진다.
인터넷 계층으로 들어가서 IP Address가 추가되고 마지막에 물리적인 전송을 한다.

패킷이 네트워크를 통과한다는 것은 전기신호를 통해 물리적으로 통과하는 것을 말한다.

패킷이 전송되어 수신하는 쪽은 역방향으로 순서가 진행된다.
네트워크 계층에서 추가한 내용이 제거되고
인터넷 계층에서 수신 측이 맞는지 검수하고
전송 계층에서 프로토콜이 포트를 확인한 후
해당하는 운영 계층의 프로토콜에 맞게 패킷 안에서 원 데이터를 추출하고 보여준다.

네트워크 프로토콜은 리눅스나 윈도우나 모두 내장되어 있기 때문에 따로 다운 받을 필요가 없다.

프로그래밍 관점에서 접근할 때 TCP 관점에서 접근할 것인지
UCP 관점에서 접근할 것인지
데이터를 수신할 대상은 아이파가 어떻게 될지 확인하면 된다.
직접 하드하게 코딩하는 방법도 있고 라이브러리를 통해 처리하는 방법도 있고 다양하다.

네트워크 패킷 분석

1. 프로그램

1.1 wireshark 프로그램

• 오픈 소스 방식의 패킷 분석 프로그램

• 네트워크를 통해 송수신되는 패킷에 대한 분석을 통해 보안 이슈나 트러블 슈팅에 대한 분석 목적으로 많이 사용

• Windows, Linux, MacOS 에서 제약없이 사용가능

• https://www.wireshark.org/

1.2. Open Source 프로그램

• 공개 프로그램 이라고도 한다.

• 기본적으로 무료 사용이 가능한 프로그램이고 또한 프로그램 소스 코드를 공개 하는 경우가 일반적이다.

• 장점

1. 무료로 프로그램 사용 가능
2. 프로그램 소스를 제공해 주므로 필요에 따라 기능을 수정하여 나만의 프로그램을 작성할 수 있다.

• 단점

1. 무료이고 명확한 관리 주체가 없는 경우가 많아서 보안 이슈나 기능 업그레이드가 수월하지 못하다.
2. 사용시 문제점이 발생하면 직접 도움을 받기 어렵다.

2. 네트워크 연결 장치 관련 용어

2.1. 네트워크 어댑터 (adapter)

네트워크 연결 장치에 대한 용어

2.2. 네트워크 장치 드라이버 (driver)

• 네트워크 연결 장치를 실제 제어하는 프로그램

• O/S 내에 설치되는 프로그램

• O/S가 사용하는 하며 실제 장치 제어 목적의 프로그램

3. Filter toolbar

Filter toolbar를 이용하여 원하는 패킷 filtering 할 수 있다.

1. icmp 패킷만 filtering

icmp

2. tcp port중 80 포트(HTTP)로 송수신되는 패킷만 filtering

tcp.port == 80

3. tcp 프로토콜 패킷만 filtering

tcp

4. 특정 IP Address로 송수신되는 패킷만 filtering

ip.addr == <IP Address>

5. Source(송신측) IP Address로 부터 수신되는 패킷만 filtering

ip.src == <IP Address>

암호화 방식 (보안기능)

보안은 내가 데이터를 전송할 때 데이터를 안전하게 보내는 것이다.

전송되는 데이터를 누가 훔쳐 보더라도 내용파악이 되지 않게 보안(암호화)를 적용한다.
인터넷은 보안성이 없기 때문에 데이터 전송 시 평문으로 보내진다.
그래서 데이터를 열어보면 다 알아볼 수 있어 신뢰성은 있지만 보안성이 떨어진다고 할 수 있다.
그래서 암호화를 통해 보안을 지킨다.

암호화된 데이터를 전송하면 상대편이 암호를 복호화하여 내용을 확인한다.

1. 대칭키(비밀키) 암호화

• 암호화(encoding)와 복호화(decoding)를 하나의 키로 수행

• 참고
  https://ko.wikipedia.org/wiki/%EB%8C%80%EC%B9%AD_%ED%82%A4_%EC%95%94%ED%98%B8

대칭키 암호화는 복호화 할 때 사용하는 암호가 같다.
그냥 하나의 키를 가지고 인코딩하고 딥코딩을 다 하는 거라 키가 탈취되면 문제가 생긴다.
예전에는 많이 사용했지만, 요즘에는 사용하지 않고 공개키를 많이 사용한다.

2. 공개키 암호화

• 개인키(비밀키)와 공개키로 구성된 암호화 방법

• 공개키는 외부로 공개를 하고 개인키는 별도로 보관함으로써 실제 암호화 내용이 유출 되더라도 안전하게 관리하는 방법

• 현재 일반적으로 사용하는 암호화 방식

• 참고
  https://ko.wikipedia.org/wiki/%EA%B3%B5%EA%B0%9C_%ED%82%A4_%EC%95%94%ED%98%B8_%EB%B0%A9%EC%8B%9D

공개키는 외부에 공개하는 키다.
공개키는 내가 가지고 있는 비밀키로 열어볼 수 있다.
따라서, 하나의 키를 사용하는 대칭키 암호화 방식에 비해 보완성이 높다.
대표적인 예로 블록체인이 공개키 암호화를 사용한다.
비대칭 키 암호화에 공개 키와 비밀(개인) 키가 있는 것이다.

GCP에서 사용하는 암호화가 공개키 암호화 방식이다.
이런 방법을 사용한 보완 웹이 HTTPS이며, HTTP는 암호화가 되지 않는다.

256비트나 128비트의 키는 주로 대칭 키 암호화 방식에서 사용된다.
256비트 암호화가 해킹되거나 취약점을 노출할 수 있는 경우가 있지만, 이는 보통 키 관리나 암호화 구현의 문제로 인해 발생한다.
512비트 키는 보통 비대칭 키 암호화 방식(RSA, ECC)에서 사용되며, 대칭 키 암호화 방식에서 512비트 키는 드물게 사용된다.
128비트 암호화 방식은 여전히 대칭 키 암호화에서 강력한 보안을 제공하며, 성능과 보안의 균형이 잘 맞는다.

보안 프로토콜

• 인터넷이라는 환경은 누구나 마음대로 사용할 수 있는 환경이고 또한 패킷의 내용을 마음대로 열어볼 수 있으므로 데이터를 송수신시 데이터에 대한 보안을 적용 할 필요가 있다.

• HTTP는 기본적으로 암호화되지 않은 데이터를 송수신한다.

• HTTPS(ecure)는 HTTP 프로토콜에 암호화를 적용한 프로토콜이고 기본 port 번호는 443번 사용

• HTTPS가 사용하는 보안 기능(암호화 방식)

웹 서버에서 데이터를 보낼 때 보안 문제가 발생할 수 있다.
웹 브라우저 환경에서는 HTTPS 환경에서 보안을 강화할 수 있다.

HTTP:// : 통상적 웹 (크롬에서는 보안 문제로 HTTP 사용을 배제하고 있는 추세다)
HTTPS:// : 보안 웹

1. SSL (Secure Sockets Layers)

• 현재 SSL 3.0 까지 나와있고 앞으로 업데이트는 없는 보안 기능

• 앞으로 업데이트가 없어 최근에는 TLS를 많이 사용한다.

2. TLS (Transport Layer Security)

• 현재 TLS 1.0 까지 나와있고 SSL의 업그레이드 버전이고 SSL과 다른 제작사에 의해서 관리

• 통상 SSL이라고 하는 보안 기능은 TLS를 의미

• HTTPS - SSL, HTTPS - TLS, HTTPS - SSL/TLS 여러가지 형태로 표기

• TLS 사용을 위해서는 인증서가 필요하다.

3. SSL/TLS 인증서

• 클라이언트와 서버간 통신을 제 3 자가 보증해주는 문서

• 클라이언트가 서버에 접속하면 서버는 클라이언트에게 인증서를 전송하고 클라이언트는 전달 받은 인증서를 보고 신뢰할 수 있는 대상인지 확인한 후 데이터를 보내는 절차를 수행

• 인증서를 통해 클라이언트와 소통할 수 있게 하며, 신뢰할 수 있는 인증서가 없으면 접송이 불가할 수 있다.

4. 통신 과정

HTTP는 연결을 계속적으로 유지하지 않는 프로토콜이므로 만약 클라이언트에 대한 정보 유지를 하려면 통산 쿠키(Cookie)를 많이 사용하였으나 보안 이슈에 의해서 요즘은 서버의 세션(session)에 정보를 관리하는 방법을 많이 사용

클라이언트가 hello를 보내면
서버는 hello에 대한 암호화 방식에 따라 클라이언트에게 인증서를 보낸다.

인증서를 통해 비대칭 암호화를 한다.
인증서 안에 있는 공개키를 이용해서 개인키를 암호화하여 서버로 전송한다.

서버닌 자기가 가지고 있는 개인 키로 복호화를 하고 인증을 한다.
그리고 대칭키(섹션키)라는 걸 생성해서 보안통로를 만든다.

HTTPS처럼 평문으로 데이터를 수신하는 게 아닌 통로를 만들어서 송수신 하는 것이다.
웹 서버 쪽에서 인증서를 관리하고 인증서를 발급할 수 있는 환경까지 구축해야 한다.
인증서는 무료가 있고, 유료가 있다.

1. 클라이언트에서 서버에 접속

• 클라이언트는 랜덤한 데이터와 현재 지원 가능한 암호화 방식 전달

2. 서버가 응답

• 인증서의 공개키

• 서버에서 생성한 랜덤한 데이터

• 가장 안전한 암호화 수단

3. 클라이언트는 내장 인증서 리스트에서 서버가 보낸 인증서 복호화

• 내장 인증서에 없는 인증서인 경우 사용자에게 경고

• 내장 인증서에 포함된 인증서인 경우 서버를 신뢰할 수 있고 클라이언트가 전송한 랜덤한 데이터와 서버가 전송해준 랜덤한 데이터를 이용하여 Pre Master Secret 키 생성

4. 서버로 부터 전송받은 공개키로 Pre Master Secret 키를 암호화하여 서버에 전송하고 서버는 개인키로 Pre Master Secret 키를 복호화하여 클라이언트와 Pre Master Secret 키를 공유한다.

5. 서버와 클라이언트는 Pre Master Secret 키를 이용하여 Master Secret 값을 만들고 Master Secret 값을 이용하여 Session key를 생성

6. 서버와 클라이언트의 세션이 생성되고 Session key를 이용하여 암호화한 데이터를 주고 받으며 통신한다. - 대칭키 암호화

TIP!

대칭키는 공개키에 비해 빠르지만 키 전송에 문제 발생 여지가 있다. 따라서 SSL 핸드쉐이킹 과정에서 Key를 공유하기 위해 공개키 암호화 방식을 이용하고 이 후 세션키를 사용할 때는 대칭키 암호화 방식을 사용

만약, HTTPS를 적용하여 서버를 구생해야 한다면, TLS 방식에 인증서로 구성을 해야 한다.
대칭키 암호화 방식이 더 빠르긴 하나 키 전송에 문제의 여지가 있다(키 자체 해킹 여지).