OSI 7계층
OSI 7계층
네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것을 말한다.
통신이 일어나는 과정을 단계별로 파악하기 위하여 나눴는데, 흐름을 한 눈에 보기 쉽고 이상이 발생했을 경우 다른 부분을 건드리지 않고 에러가 난 단계만 고치면 해결할 수 있기 때문이다
TCP/IP
현재 인터넷에서 컴퓨터들이 서로 정보를 주고받는데 활용되는 프로토콜의 모음이다.
HW, OS, 접속 매체 관계없이 동작할 수 있는 개방성을 가진다.
OSI 7계층과 TCP/IP 계층의 차이
TCP/IP 계층이 먼저 개발되었다.
TCP/IP 계층은 실제로 활용되는 프로토콜로써 지속적인 표준화를 통해 우수한 신뢰성을 가지지만, OSI 계층은 표준이지만 구현은 적어 신뢰성이 낮다.
OSI 계층을 표준으로 활용한다고는 하지만, 실제 통신 자체는 TCP/IP를 활용한다.
TCP vs UDP
TCP
TCP는 연결 지향적 프토코롤로써, "신뢰성 있는 통신"을 위해 활용하는 프로토콜이다.
TCP 프로토콜은 신뢰성 있는 데이터 전송을 위해 확인 작업을 거치는데, 3-way-handshake 과정을 통해 이 작업을 실행한다.
TCP는 1:1 통신만 가능하며, 데이터를 보내기 전 반드시 "연결"이 형성되어야 한다.
TCP는 데이터의 전송 순서를 보장하며, Sequence Number와 ACK Number를 통해 신뢰성을 보장한다.
또한 데이터 흐름을 제어하고 혼잡 제어도 수행하여 통신에 과부하가 일어나지 않도록 조절해준다.
UDP
UDP는 비연결 지향적 프로토콜로써 데이터를 주고받을 때 연결 절차를 거치지 않고 발신자가 일방적으로 데이터를 보내는 것이다.
확인 작업을 거치지 않고 전송을 하기 때문에 빠르지만, 신뢰성은 떨어진다.
UDP는 패킷의 순서가 지켜지지 않으며, 패킷이 없어질수도 있다. 이럴 경우 TCP는 다시 응답을 보내 서버에 데이터를 요청하지만, UDP는 데이터를 재전송하지 않는다.
즉, 의미있는 서버를 만들기 위해서는 패킷 관리에 신경을 써줘야 한다는 것이다
TCP vs UDP
TCP와 UDP는 포트 번호를 이용하여 주소를 지정하고, 데이터 오류 검사를 위한 Checksum은 Header에 존재한다.
하지만 TCP는 연결이 되어야지만 데이터를 보낼 수 있는 것과 달리, UDP는 연결이 되어 있는지 여부는 신경쓰지 않고 데이터를 보낸다.
TCP는 전송 순서가 보장되지만, UDP는 전송 순서가 바뀔 수 있으며 TCP는 신뢰성이 높지만 속도가 느리고 UDP는 신뢰성이 낮지만 속도가 빠르다.
UDP Header
송신 / 수신자의 Port 번호와 데이터 길이, 데이터 오류 검사를 위한 Checksum만 존재한다.
하지만 TCP는 포트번호 이외에도 ACK Number, 제어 비트, Sequence번호 등 신뢰성 확인을 위한 많은 데이터가 존재한다.
3-way handshake와 4-way handshake
3 Way Handshake는 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정을 의미한다.
먼저 Client에서 Server 쪽으로 신호를 보내면, Server는 이를 수락하며 Client에게 요청을 보낸다
Client는 받은 데이터를 통해 세션을 생성하고, 다시 Server에게 확인 메시지를 보낸다. 이 경우 성공적으로 세션이 수립된다.
총 3번의 통신 과정이 존재하므로 3-way handshake라고 한다.
3-way handshake가 TCP의 연결을 초기화할 때(세션을 생성할 때) 활용되었다면, 4-Way Handshake는 세션을 종료하기 위해 수행되는 절차이다
3-way handshake와 매우 유사하다. 그런데 문제는, Server를 종료할 때 서버가 실행하고 있는 수행 과정중인 Thread 등이 존재할 수 있다.
따라서, Server는 Client에게 요청을 받았을 때, 일단 종료를 요청하는 신호는 받았다는 것을 먼저 알린다.
이후, Server 또한 연결을 종료할 준비가 되었을 때 연결 해제를 위한 준비가 되었음을 알리기 위해 다시 신호를 보낸다.
이후 Client는 해지준비가 되었다는 신호를 다시 Server에게 보내고, 최종적으로 Client-Server 간의 연결이 끊어지는 것이다
여기서 문제가 하나 생긴다.
Server가 Client에게 종료를 해도 된다고 FIN 신호를 보냈고, Client는 이를 받았다고 가정하자. 그런데, FIN 신호를 보내기 이전에 전송한 패킷이 특정 이유(Routing 지연, 패킷 유실으로 인한 재전송 등)로 FIN 신호보다 늦게 도착하는 상황이 발생하면, 이전에 전송한 패킷이 사라지게 되는 것일까?
이를 위해 Client는 Server로부터 FIN을 수신하더라도 일정시간동안 세션을 남겨 놓고 남아 있는 패킷을 기다리는 과정을 거친다.
이 과정을 "TIME_WAIT"이라고 하며 설정한 시간이 지나면 세션을 그때서야 세션을 만료하고 연결을 종료시킨다.
혼잡제어 vs 흐름제어
흐름 제어
송신 측의 속도가 수신 측의 처리속도보다 빠를 경우, 수신 측에서 송신 측의 데이터를 받다가 메모리 과부하가 걸려 패킷이 손실될 수 있고, 이 때문에 불필요한 추가 패킷 전송이 발생할 수 있다.
이런 문제를 해결하기 위해 나온 기법이 흐름제어이다.
방법은 1개 패킷씩 보내는 Stop and Wait, 수신 측에서 설정한 윈도우 크기만큼 송신 측에서 데이터를 보낼 수 있는 Sliding Window 기법이 존재한다.
혼잡 제어
데이터의 양이 너무 많아 Router가 처리할 수 있는 양을 초과하면 초과된 데이터는 라우터가 처리하지 못한다.
송신 측에서는 라우터가 처리하지 못한 데이터를 손실 데이터로 간주하여 계속 재전송할 것이다.
즉, 라우터는 과부화인데 계속 손실 데이터라고 생각하여 데이터를 보내니 네트워크가 과부하가 걸릴 것이다.
이런 상황을 막기 위해서 송신측의 전송 속도를 적절히 조절하여 예방하는 것이 혼잡 제어이다.
즉, 흐름 제어는 "송/수신측 패킷 수"를 제어하는 것, 혼잡 제어는 "네트워크 내 패킷 수"를 제어하는 것이다.
혼잡 제어 기법으로는 AIMD(전송에 성공하면 +1, 실패할 경우 윈도우 크기를 반으로 줄여 데이터를 보냄), Slow Start(전송에 성공할 경우 지수적, *2 씩 증가시키다가 혼잡이 감지되면 Window 크기를 1로 줄이는 방식), 빠른 재전송(순서대로 잘 도착한 마지막 패킷의 다음 순번을 ACK 패킷에 실어 보내 패킷 재전송 여부를 확인해주는 것), 빠른 회복(혼잡한 상태가 되면 윈도우 크기를 반으로 줄이고 다시 선형 증가시키는 방법)이 있다.
TCP Tahoe라는 Slow Start를 활용하다 ssthresh를 만난 이후부터 AIMD를 활용하는 기법, TCP Reno라는 TCP Tahoe 정책에서 3 ACK Duplicated와 Timeout 혼잡 상황을 구분하는 기법이 존재한다.
TCP Reno에서는 3 ACK Duplicated는 큰 혼잡이 아니라고 판단하여 반으로 줄이지만, Timeout은 심각하다고 생각하여 윈도우 크기를 1로 만든다
데이터 명칭들
Segment
Transport Layer에서 부르는 데이터 명칭으로 Port 번호를 Header로 가진다.
Packet
Network Layer에서 부르는 데이터 명칭으로 IP 주소를 Header에 포함한다.
Frame
Datalink Layer에서 부르는 데이터 명칭으로 MAC 주소를 Header에 포함한다.
Frame Header는 LAN에 있을 경우는 MAC 주소이지만, WAN 영역일 경우 WAN 영역에 대한 정보로 채워진다.
Datagram
사용자의 순수한 메시지로, 사용자가 보내길 원하는 데이터를 의미한다.
암호화
대칭키
암, 복호화에 사용하는 키가 동일한 암호화 방식이다.
키가 동일하기 때문에 키를 아는 사람만이 문서를 복호화 할 수 있고, 암호화도 가능해진다.
따라서 암, 복호화 하는 사람은 항상 암호화 방식에 대한 키를 가지고 있어야 한다.
여기서 발생하는 문제는 키를 교환하는 과정에서 키가 탈취될 수도 있으며, 암호화 방식이 다양해질수록 관리해야 할 키가 많아진다는 점이다.
하지만, 복잡한 알고리즘은 아니므로 암, 복호화에 긴 시간이 걸리지는 않는다는 장점이 있다
비대칭키(공개키)
암, 복호화에 사용되는 키가 서로 다른 암호화 방식이다.
공개키는 모든 사람이 접근 가능한 키이며, 개인키는 각 사용자만이 가지고 있는 키이다.
공개키를 통해 암호화를 진행하고, 개인키를 통해 복호화를 진행한다.
A가 B에게 데이터를 보내고 싶은데, B가 개인키를 가지고 있다고 가정하면
- B가 공개키/개인키 쌍 생성
- 공개키 등록 & 개인키 보관
- A가 B의 공개키 받아 암호화
- B는 암호화된 데이터를 받아 B의 개인키로 복호화
공개키는 암호화를 위한 키가 공개되어 있기 때문에 키 교환이나 분배를 할 필요가 없다.
공개키를 만약 탈취한다고 하더라도, 개인키를 가지고 있지 않으면 복호화가 불가능하므로 보안의 3요소(CIA; 기밀성, 무결성, 가용성)을 지킬 수 있다는 장점도 존재한다.
대신, 복잡한 과정을 거치므로 대칭키 암호화 방식에 비해 속도가 느리다.
HTTP vs HTTPS
HTTP란?
서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜이다.
인터넷에서 Hypertext를 교환하기 위한 통신 규약으로, 80 포트를 활용한다.
HTTP는 Stateless Protocol로써 Method, Path, Protocol Version과 Header, Body로 구성되어 있다.
하지만, 암호화가 되지 않고 평문 데이터를 전송하기 때문에 제3자가 정보를 탈취할 수 있는 보안 문제가 발생할 수 있다.
HTTPS란?
HTTP에 데이터 암호화가 추가된 프로토콜이다.
암호화 방식은 대칭키 암호화, 비대칭키 암호화 방식이 존재하는데, HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 연산과 언정성 모두를 얻은 프로토콜이다.
Client가 Server로 연결 시도를 할 때, Server는 공개키(인증서)를 브라우저에게 전달하고, Browser는 인증서의 유효성을 검사하여 세션키를 발급한다.(Browser는 Client라고 생각해도 된다)
이 세션키를 Server의 공개키로 암호화하여 Server로 전송한다.
서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻고, 아까 Browser에 저장된 Session Key와 동일한 키 값을 가질 것이므로 연결이 성립된다.
HTTP Method
GET은 정보를 요청하는 메서드이다.
URI에 변수(데이터)를 포함시켜 요청하며, Header에 데이터를 포함시켜 전송한다.
보안상 취약할 수는 있으나 캐싱이 가능하다.
POST는 정보를 입력하기 위한 메서드이다.
URI가 아닌 Packet Body에 데이터를 포함시켜 전송하기 때문에 데이터가 노출되지 않아 안전하지만, 캐싱이 불가능하다.
다만, Architecture적으로 수정을 가해 캐싱이 가능하도록 만들 수는 있다
REST
REST
정보를 주고받을 떄 많이 활용되는 형식으로, 자원에 대한 CRUD 연산을 수행하기 위해 URI(자원)로 HTTP Method(방식)을 활용하여 요청을 보내고, 이 요청을 "어떤 형식"의 데이터로 주고 받을지 정하여 Request를 보내는 것을 말한다.
요청만 보고서도 어떤 작업을 수행할 수 있을지 추론 가능하다는 특징을 가진다.
RESTful이란?
REST 설계 규칙을 잘 지키는 시스템을 RESTful이라는 용어로 지칭한다.
즉, REST API는 REST의 특징을 기반으로 서비스 API를 구현한 것이고, RESTful API는 API를 구현했는데 이 API가 REST 원리를 잘 따를 경우 RESTful API라고 한다.
CORS
CORS란?
교차 출처 리소스 공유의 약어이다.
HTTP Header를 추가로 사용하여 1개의 출처에서 실행 중인 Web Application이 다른 출처의 자원에 접근할 수 있는 권한을 부여하도록 브라우저에서 알려주는 체제이다.
즉, 다른 Origin을 가진 Application이 서로 통신할 수 있게 허용하는 프로토콜을 의미한다.
CORS의 활용 이유
Project에서 Client의 크기가 커질수록 Client를 별도로 관리하기 위한 별도의 origin을 가질 것이고, Server 또한 별도의 origin을 가질 것이다.
보안적인 이슈로 다른 origin에 넣는 경우도 존재한다.
(User가 서버에 접속하는 불상사가 일어나면 안되기 때문)
이 때문에, 다른 origin을 가져도 통신이 가능해져야 했으며, 이를 위해 CORS가 필요해졌다
쿠키와 세션
쿠키
Client Local에 저장되는 키와 값이 들어있는 작은 데이터 파일로 유효 시간이 정해지면 브라우저 종료 여부와 관계 없이 인증이 유지된다는 특징을 가진다.
쿠키는 클라이언트가 페이지를 요청할 때, 서버에서 쿠키를 생성하고 HTTP 헤더에 쿠키를 포함 시켜 응답을 보내면 브라우저에서 쿠키를 저장하는 형식으로 동작한다.
만약, 저장된 쿠키를 활용할 경우 HTTP Header에 쿠키를 담아 보내고, Server 쪽에서는 받은 쿠키를 Update하거나 이전 상태와 비교하여 응답한다.
세션
쿠키를 기반으로 하지만, 서버 측에서 사용자 정보 파일을 관리한다.
세션은 클라이언트를 구분하기 위해 세션 ID가 부여되며, 브라우저가 종료될 때까지 인증상태를 유지한다.
서버에 사용자 정보를 두기 때문에 쿠키보다 보안은 좋으나 서버 메모리를 많이 차지하게 된다.
클라이언트가 서버에 접속할 떄 세션 ID를 발급받는데(3-way Handshake나 HTTPS 동작 방식) 클라이언트는 세션 ID에 대해 쿠키를 활용해서 저장하고 있다.
클라이언트 서버에 Request를 보낼 때 세션 ID를 같이 보내며, 서버는 세션 ID로 세션에 있는 클라이언트 정보를 가져와서 활용하는 것이다.
쿠키와 세션 차이
가장 큰 차이점은 사용자의 정보가 저장되는 위치라고 할 수 있다.
세션도 결국 쿠키를 활용하긴 하지만, 세션은 사용자 정보를 서버에 저장하고 쿠키는 Local에 저장한다.
쿠키는 "데이터"를 담아서 보내지만, 세션은 session ID를 통해서 Server에 요청한다. 따라서, 비교적 보안상 세션이 좋다.
세션도 만료기간이 존재하긴 하지만, 브라우저가 종료되면 만료기간과 관계없이 삭제된다.
같은 브라우저의 다른 탭은 같은 세션을 공유하지만, 다른 브라우저는 다른 세션을 활용하는 것이다.
(쿠키는 만료기간이 안되었으면 브라우저 종료되어도 생성)
DNS
DNS란?
도메인 네임 시스템의 줄임말로, Host의 Domain Name을 네트워크 주소로 바꾸거나 반대 변환을 할 수 있도록 개발된 시스템이다.
웹 서버 주소에 해당하는 IP 주소 테이블을 가지고 있는 서버로써, DNS Query를 통해 DNS 서버에서 Domain Name을 이용하여 IP를 받아오고 받아온 IP 주소를 활용해 네트워크 통신을 실시하는 과정이 DNS 시스템에서 일어나는 과정이다
DNS Round Robin
Round Robin은 선점형 스케줄링의 방법 중 하나이다.
프로세스의 우선순위를 두지 않고, 프로세스에게 순서대로 시간단위만큼 CPU를 할당하는 방식이다.
DNS 서버를 Round Robin 형식으로 구성할 경우 부하에 대한 걱정을 할 필요가 없어 Load Balancer가 필요 없다는 장점은 가지지만, 서버 다운에 대한 확인이 불가하며 서버의 수만큼 공인 IP 주소가 필요하고 RR 자체가 균등하게 자원을 분배하지는 않는 스케줄링 기법이라는 단점이 존재한다.
웹 통신 흐름
-
사용자가 브라우저에 도메인 이름을 입력
-
DNS 서버에서 매핑되는 IP 주소를 찾아 반환함
-
IP 주소는 HTTP Protocol을이용해 HTTP Request Message를 생성하고 TCP 프로토콜을 활용해 보냄
-
인터넷을 거쳐 Server측 TCP에 도달하고, 서버까지 Message가 도달함
-
Request에 대한 응답을 수행하고, Respond Message를 만들어 전송함
-
HTTP Respond Message는 HTTP Protocol을 활용하여 Web Page Data로 변환하여 Browser의 출력에 의해 사용자가 볼 수 있음
TLS Handshake / SSL Handshake
- 둘 모두 같은 개념
SSL Handshake는 통신을 하는 Browser와 Web Server가 암호화 통신을 수행할 수 있도록 신분을 확인하고 필요한 정보를 클라이언트와 서버가 주고 받는 과정을 말한다.
과정은 아래와 같다.
-
서버는 CA에 사이트 정보 및 공개 키를 전달하여 인증서를 받음
- CA에 공개키와 사이트 정보를 전달하여 등록하는 것
- CA에서 사이트 정보와 공개키에 대해 암호화하여 인증서를 생성하고 사이트에 전달해줌
-
Client는 Browser에 CA 공개 키가 내장되어 있음
-
ClientHello
- 사용자는 Site에 접속을 요청함
-
Serverhello
- 사이트는 사용자에게 자신의 SSL Protocol Version을 알림
-
Server Certificate
- 사이트는 인증서를 사용자에게 전송함
- 이증서 및 Browser CA를 활용해 인증서가 유효한지 검증하고, 사이트의 공개 키를 가지고 옴
-
Client Key Exchange
- 5 과정을 통해 사이트의 공개 키를 얻었으므로 해당 키를 활용해 "사용자의 대칭키"와 암호화된 파일을 보낸다
- 사용자의 대칭키를 보냄으로써, Web Server가 개인키를 통해 복호화하면 대칭키에 대한 정보도 알 수 있고, 대칭키를 통해 암호화된 값도 복호화 시킬 수 있음
-
Client/ServerHello done
- 모든 과정이 끝나 사용자 개인키를 Web Server와 Client가 모두 가지고 있고, 이제는 암호화하여 서로 통신 할 수 있음
-
Finished
Blocking, Non-blocking, Synchronous, Asynchronous
Blockinig
A 함수가 B함수를 호출 할 때, B 함수 작업이 종료되기 전까지 A 함수에게 제어권을 알려주지 않는 것
Non-Blocking
A함수가 B함수를 호출할 때, B 함수가 제어권을 바로 A함수에게 넘겨줘 A 함수가 다른 작업을 할 수 있도록 해주는 것
동기(Synchronous)
A 함수가 B 함수를 호출할 때 B 함수 결과를 A 함수가 처리하는 것
비동기(Asynchronous)
A 함수가 B 함수를 호출할 때, B 함수 결과를 B 함수가 처리하는 Callback
설명
-
Blocking + Synchronous
A 함수가 B 함수를 호출했다. 현재 제어권은 B함수에게 존재한다.
또한 동기이기 때문에 B 함수 결과도 A 함수가 처리해야 한다.
즉, 제어권이 B 함수에 있기 때문에 아무런 작업을 하지 못하고, B 작업이 종료되어야지만 반환 값을 처리하고 A 작업이 수행된다 -
Async + Non-Blocking
A 함수가 B 함수를 호출했지만, 제어권은 A함수가 가지고 있다. 따라서, A 함수는 다른 일을 수행할 수 있다.
이후 Callback이 호출될 때 B함수의 Output을 처리하는 것이다. -
Sync + Nonblocking
Nonblocking이므로 일단 A가 제어권을 가지고 있다.
따라서 A는 계속해서 다른일을 수행할 것이다.
하지만, 작업은 Sync이다.
즉, B함수 종료를 A 함수가 처리해줘야 하기 때문에 A 함수는 수시로 B 함수에게 함수 종료 여부를 물어보고, 나중에 종료되었음을 알게 되면 종료시켜야 한다 -
Async + Blocking
애초에 Blocking이므로 제어권은 B가 가지고, 따라서 A는 아무것도 못한다.
Async이므로 함수 종료 또한 B함수에서 수행하므로, Callback을 호출하여 B함수가 종료된 이후에서야 A가 작업을 수행할 수 있을 것이다
정말 비효율적인 케이스이므로, 굳이 사용하지 않는다
