국제 표준화단체 ISO(International Standard Organiztion)에서 정한 네트워크 연결 시스템이다. HTTP 프로토콜을 이용하여 데이터를 요청하면, 응용 계층부터 위에서 밑으로 차례로 전달된다. 데이터를 받는 과정을 반대로 물리 계층부터 응용 계층으로 올라간다.
위의 그림과 같이 7개의 영역으로 나누어져 있다.
응용계층, 표현계층, 세션계층, 전송계층, 네트워크계층, 데이터링크계층, 물리계층
물데네전세표응
이 계층에서는 주로 전기적, 기계적, 기능적인 특성을 이용하여 통신 케이블로 데이터를 전송하게 된다. 이 계층에서 사용되는 통신단위는 비트이며 이것은 1과 0으로 나타내어지는, 즉 전기적으로 On, Off 상태라고 생각하면 된다.
이 계층에서는 단지 데이터를 전달할 뿐, 데이터가 무엇인지, 어떤 에러가 있는지 등은 전혀 신경쓰지 않는다. 단지 데이터를 전기적 신호로 변환해서 주고받는 기능만 할 뿐이다.
이 계층에 속하는 대표적인 장비는 통신 케이블, 리피터, 허브 등이 있다.
물리 계층을 통해 송수신되는 정보의 오류와 흐름을 관리하여 안전한 정보의 전달을 수행할 수 있도록 도와주는 역할을 한다. 따라서 통신에서의 오류를 찾아주고 재전송도 하는 기능을 가지고 있다.
이 계층에서는 맥 주소를 가지고 통신하게 된다. 이 계층에서는 전송하는 단위를 프레임이라 한다. 그리고 물리적 오류를 감지하는 기능을 담당하며, 오류(데이터 분실 or 내용의 파손)를 감지하면 송신자가 원래 데이터를 재전송함으로 일반적으로 처리한다.
대표적인 장비로는 브리지, 스위치 등이 있다.
송신 호스트가 전송한 데이터가 어떤 경로를 통해 전달되는지 결정하는 라우팅 문제를 다룬다. 네트워크 계층에서의 전송 데이터를 패킷이라 부르며, 네트워크를 이용해 지나치게 많은 패킷이 전송되면, 전송속도가 떨어질 수 있으므로 이를 제어하는 혼잡제어 기능도 담당한다.
라우팅
데이터가 지나갈 경로를 선택해서 이동하는 것을 말함. 즉, 경로 설정
전송계층은 송수신 프로세스 간 직접 연결하는 통신기능을 합니다. 전송계층의 하위계층(네트워크계층, 데이터링크계층)은 호스트와 호스트 사이에 데이터 전송과정에서 발생하는 문제들을 다루지만, 전송계층에서는 컴퓨터 내부의 구축되는 통신당사자인 프로세스 사이의 통신문제를 다룬다. 또한, 사용자의 서비스 요구유형에 대한 고려, 전송 오류율, 전송속도 등에 대한 흐름제어 기능도 제공한다.
세션계층의 기능은 전송계층과 매우 유사하다. 하지만 사용자가 원격파일로 전송하거나 원격 로그인 등과 같은 상위적 연결 개념인 세션 기능을 제공하는 부분이다. 또한, 송수신 호스트 사이 대화 제어 등의 동작을 제어하기 위한 토큰제어, 일시적 전송장애를 해결하는 동기화 기능을 제공한다.
5계층까지는(세션계층 ~ 물리계층) 데이터 전송에 관한 내용을 다루지만 표현계층은 데이터의 의미와 표현방법을 처리한다. 통신 양단에서 서로 이해할 수 있는 표준방식으로 데이터를 코딩하는 문제를 다룬다.
호스트의 데이터 표현방법이 서로 다를 수 있는데, 이러한 데이터를 이해할 수 있도록 적절하게 변환한다. 또, 보안시 중요시 되고 있는 데이터를 암호화하는 기술, 영상 정보같은 대용량의 데이터 크기를 압축하는 기능도 표현계층에서 처리
사용자 또는 어플리케이션이 네트워크에 접근할 수 있도록 메일 전송, 인터넷 접속 작업 등을 수행한다.
예를 들면 FTP와 같은 것이 이 계층에 속한다.
TCP/IP는 현재의 인터넷에서 컴퓨터들이 서로 정보를 주고 받은데 쓰이는 통신규약(프로토콜)의 모음이다.
OSI 7계층에서 물리계층과 데이터링크 계층에 해당한다.
OS의 네트워크 카드와 디바이스 드라이버 등과 같이 하드웨어적인 요소와 관련되는 모든 것을 지원하는 계층.
송신측 컴퓨터의 경우 상위 계층으로부터 전달받은 패킷에 물리적인 주소는 MAC 주소정보를 가지고 있는 레더를 추가하여 프레임을 만들고, 프레임을 하위계층인 물리계층으로 전달한다.
수신측 컴퓨터의 경우 데이터링크 계층에서 추가된 헤더를 제거하여 상위 계층인 네트워크 계층으로 전달한다.
CSMA/CD, MAC, LAN, X25, 패킷망, 위성통신, 다이얼 모뎀 등 전송에 사용
프로토콜: Ethernet(이더넷), Token Ring, PPP
OSI 7계층에서 네트워크 계층에 해당한다.
상위 트랜스포트 계층으로부터 받은 데이터에 IP패킷 헤더를 붙여 IP패킷을 만들고 이를 전송하는 것이다.
통신 노드간의 IP 패킷을 전송하는 기능 및 라우팅 기능을 담당
프로토콜: IP, ARP, RARP, ICMP, OSPF
OSI 7계층에서 전송계층에 해당한다.
네트워크 양단의 송수신 호스트 사이에서 신뢰성 있는 전송기능을 제공한다.
시스템의 논리주소와 포트를 가지고 있어서 각 상위 계층의 프로세스를 연결해서 통신한다.
정확한 패킷의 전송을 보장하는 TCP와 정확한 전송을 보장하지 않는 UDP 프로토콜을 이용한다.
데이터의 정확한 전송보다는 빠른 속도의 전송이 필요한 멀티미디어 통신에서 UDP를 사용하면 TCP보다 유용하다.
통신 노드 간의 연결을 제어하고, 자료의 송수신을 담당
프로토콜: TCP, UDP
OSI 7계층에서 세션계층, 표현계층, 응용계층에 해당한다.
응용프로그램들이 네투워크서비스, 메일서비스, 웹서비스 등을 할수 있도록 표준적인 인터페이스를 제공한다.
TCP/IP 기반의 응용 프로그램을 구분할 때 사용한다.
프로토콜: HTTP, FTP, Telnet, DNS, SMTP
DNS란, Domain Name System의 약자로서, 사람이 읽을수 있는 도메인 이름(ex. velog.io)을 컴퓨터가 읽을 수 있는 IP주소(ex. 192.168.0.1)로 변환하거나, 반대로 변환하는 시스템.
웹 상에서 서버/클라이언트 모델을 따라 데이터를 주고받기 위한 응용계층 프로토콜로 TCP/IP 위에서 작동한다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며, Method, Path, Version, Header, Body 등으로 구성된다.
프로토콜
컴퓨터간 데이터 통신을 원할히 하기 위해 규정한 약속, 신호 송신의 순서(handshaking)나 데이터 표현법, 오류 검출법 등을 정한 것
Cookie / Sesstion
HTTP의 Stateless를 극복하기 위해 사용하는 방식이다.
Cookie에 클라이언트에 대한 정보를 저장해뒀다가 사용하거나 Session을 등록해서 유지하는 방식으로 극복한다.
위 세가지 문제점은 다른 암호화하지 않는 프로토콜에서도 공통되는 문제점들이다.
TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신할 경우 메세지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.
SSL(Secure Socket Layer)
or TLS(Transport Layer Security)
라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS(HTTP Secure)
or HTTP over SSL
이라고 부른다.HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기 떄문에 누구든지 Request를 보낼 수 있다. IP주소나 포트 등에서 그 웹서버에 액세스 제한이 없는 경우 Request가 오면 상대가 누구든지 무언가 Resonse를 반환한다. 이러한 특징은 여러 문제점을 유발한다.
위 암호화 방법으로 언급된 SSL로 상대를 확인할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로 써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인정보 누설 등의 위험성이 줄어들게 된다. 한 가지 이점을 더 꼽자면, 클라이언트는 이 증명서로 본인 확인을 하고 웹사이트 인증에서도 이용할 수 있다.
여기서 완전성이란 정보의 정확성을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다는 것을 보장할 수없다는 것이다. Reqeust나 Response가 발신된 후에 상대가 수신하는 사이 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 Request나 Response를 빼앗아 변조하는 공경을 중간자 공격(Man-in-the-Middle)이라고 부른다.
MD5
, SHA-1
등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 롹인할 수 있는것은 아니다. 확실히 방지하기에는 HTTPS
를 사용해야 한다. SSL에는 인증이나 암호화, 다이제스트 기능을 제공하고 있다.
HTTPS
는 SSL의 껍질을 덮어쓴 HTTP라고 할 수 있다. 즉, HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니라는 것이다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer)
or TLS(Transfer Layer Security)
라는 프로토콜을 대체하는 것 뿐이다. HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고, SSL이 TCP와 통신하게 된다. SSL을 사용한 HTTPS는 암호화와 증명서, 안정성 보호를 할 수 있게 된다.
HTTPS의 SSL에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.
평문 통신에 비해 암호화 통신은 CPU나 메모이 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.
하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라고 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함꼐한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용했지만, 현재는 모든 웹페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.
둘 다 HTTP 프로토콜을 이용해서 서버에 무엇인가를 요청할 때 사용하는 방식이다. 하지만 둘의 특징을 제대로 이해하여 기술의 목적에 맞게 알맞은 용도에 사용해야 한다.
GET 방식은 어떠한 데이터를 조회하기 위해 사용되는 방식이다.
GET 방식은 요청하는 데이터가 HTTP Request Message
의 Header 부분에 url이 담겨서 전송된다. 때문에 url상에 ?
뒤에 데이터가 붙어 request를 보내게 되는 것이다. 이러한 방식은 url이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이다. 또, url상에 모든 데이터가 담겨 있으므로 Body는 보통 빈 상태로 전송된다.
보안이 필요한 데이터(ex. password)에 대해서는 데이터가 그대로 url에 노출되므로 GET
방식은 적절하지 않다.
ex)
url: https://search.naver.com/search.naver?query=velog
-> 네이버에 'velog'라는 키워드를 검색한 결과.
이 때에 query라는 파라미터에 velog라는 데이터를 담아서 보낸 것이다.
Caching(캐싱)
한번 접근 후, 이후에 다시 요청할 시 데이터에 빠르게 접근하기 위해 레지스터에 데이터를 저장시켜 놓는 것.
POST 방식은 데이터를 서버로 보냄으로써 데이터를 추가 또는 수정하기 위애 사용하는 방식이다.
POST 방식의 request는 HTTP Request Message
의 Body 부분에 데이터가 담겨서 전송된다. 때문에 바이너리 데이터를 요청하는 경우 POST 방식으로 보내야 하는 것처럼 데이터 크기가 GET 방식보다는 크고 보안면에서는 낫다. 하지만 암호화를 하지 않는 이상 보안적인 측면은 고만고만하다. POST 방식은 Header 부분에 Content-Type
에 Body의 데이터가 어떤 데이터 타입인지 지정해야 한다.
POST 방식은 URL에 데이터가 노출되지 않으므로 캐싱이 불가능하지만 쿼리스트링(문자열) 데이터 뿐 아니라 라디오 버튼, 텍스트 박스와 같은 객체들의 값도 전송이 가능하다.
위의 내용을 기준으로 비교 해보면 아래와 같다.
GET | POST | |
---|---|---|
URL에 데이터 노출 여부 | O | X |
URL 형식 | http://localhost:8080/board?name=제목&contents=내용 | http://localhost:8080/board |
데이터의 위치 | Header | Body |
캐싱 가능 여부 | O | X |
클라이언트와 서버가 통신을 하기 전 정확한 전송을 보장하기 위해 컴퓨터간 세션을 수립하는 과정으로써, TCP 프로토콜에서 신뢰성을 보장하기 위해 사용된다.
아래는 두 용어의 약자이다.
SYN: SYnchronize sequence Numbers
ACK: ACKnowledgment
TCP Header에는 Code Bit(Flag bit)라는 부분이 존재한다. 이 부분은 총 6Bit로 이루어져 있으며 각각 하나의 bit마다 의미를 갖고 있다. Urg-Ack-Psh-Rst-Syn-Fin 순서로 되어있으며, 해당 위치의 bit가 1이면 해당 패킷이 어떠한 내용을 담고 있는 패킷인지를 나타낸다. 예를 들면 SYN 패킷의 경우에는 000010이 되고 ACK 패킷의 경우에는 010000이 된다.
연결을 성립하기 위해서는 서로 통신이 가능한지 파악해야 한다. 이를 위해 패킷을 먼저 주고 받아야 한다. 하지만 굳이 두 종류의 패킷을 사용하는 이유는 요청과 응답에 대한 패킷을 주고 받아야 하기 때문이다.
클라이언트가 서버에게 패킷을 보내 통신이 가능한지 확인하는 것과 별개로 그 반대인 서버가 클라이언트에게 패킷을 보내 클라이언트가 잘 수신하는지 확인할 필요가 있기 때문이다. 따라서 2way로는 부족하다.
비유를 들어보자.
클라이언트가 서버에게 자신의 목소리가 들리는지 물어본다 (SYN)
서버는 클라이언트의 목소리다 들린다고 말한다.(SYN+1) 그리고 자신의 목소리가 들리는지 물어본다.(ACK)
클라이언트는 서버의 목소리가 잘 들린다고 말한다.(ACK+1)
위와 같은 과정으로 서로 통신이 가능한지 확인한다.
처음 클라이언트에서 SYN 패킷을 보낼 때 Sequence Number에는 랜덤한 숫자가 담겨진다. 초기 Sequence Number를 ISN이라고 한다. ISN이 0부터 시작하지 않고 난수를 생성해서 number를 설정하는 이유는 무엇인가?
Connection을 맺을 때 사용하는 포트(port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 보고 패킷을 구분하게 되는데, 난수가 아닌 순차적인 number가 전송된다면 이전의 connection으로부터 오는 패킷으로 인식할 수 있다. 이러한 문제를 발생할 가능성을 줄이기 위해 난수로 ISN을 설정한다.
연결지향형 전송규약
비연결지향형 전송규약
프로토콜 종류 | TCP | UDP |
---|---|---|
연결방식 | 연결지향형 전송규약 | 비연결지향형 전송규약 |
패킷 교환 방식 | 세그먼트 방식 | 데이터그램 방식 |
전송 순서 보장 | O | X |
수신 여부 확인 | O | X |
통신 방식 | 1:1 | 1:1 / 1:N / N:N |
신뢰성 | 높다 | 낮다 |
속도 | 느리다 | 빠르다 |
웹 브라우저에서 주소창에 특정 URL을 입력하면 일어나는 일
이 때 만들어진 메세지 전송을 브라우저가 직접 하는 것이 아니다. 브라우저는 메세지를 네트워크에 송출하는 기능이 없으므로 OS에 의뢰하여 메세지를 전달한다. 비유를 하자면 우리가 택배를 보낼 때 직접 보내는 것이 아니라, 이미 서비스가 이루어지고 있는 택배 시스템(택배 회사)을 이용하여 보내는 것과 같다. 단, OS에 송신을 의뢰할 때는 도메인명이 아니라 ip주소로 메세지를 받을 살대를 지정해야 하는데, 이 과정에서 DNS서버를 조회해야 한다.
프로토콜 스택은 통신 중 오류가 발생했을 때, 이 제어정보를 사용하여 고쳐 보내거나, 각종 상황을 조절하는 등 다양한 역할을 하게 된다. 네트워크 세계에서는 비서가 있어서 우리가 비서를 물만 건네주면, 받는 사람의 주소와 각종 유의사항을 써준다. 여기서는 프로토콜 스택이 비서의 역할을 한다고 볼 수 있다.
굳이 서버까지 가지 않아도 되는 경우를 골라낸다. 액세스한 페이지의 데이터가 캐시서버에 있으면 웹서버에 의뢰하지 않고 바로 그 값을 읽을 수 있다. 페이지의 데이터 중에 다시 이용할 수 있는 것이 있으면 캐시 서버에 저장된다.
참고
https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Network
https://mangkyu.tistory.com/17
https://asfirstalways.tistory.com/356
https://tuhbm.github.io/2017/09/08/OSI7/
https://ryusae.tistory.com/4
https://mindnet.tistory.com/entry/네트워크-쉽게-이해하기-22편-TCP-3-WayHandshake-4-WayHandshake