국제 표준화 기구 ISO에서 만든, 네트워크 프로토콜 디자인과 통신을 계층으로 구분해 놓은 것을 말합니다.
Application, Presentation, Session, Transport, Network, Data Link, Physical, 7계층으로 구성이 되어있습니다.
7 단계가 독립적으로 이루어져있어, 이상이 생긴 계층만 수정하면 된다는 장점이 있습니다.
Application 층은 사용자나 APP이 네트워크에 접근할 수 있도록 도와주고, 사용자를 위한 인터페이스를 지원합니다.
Presentation 층은 Application 계층으로부터 전달받거나 전송되어온 데이터의 인코딩 및 디코딩을 하는 계층입니다.
Session 층은 네트워크 상 양쪽의 연결을 관리하고, 연결을 유지시켜주는 계층입니다. TCP/IP와 같은 세션을 만들고 없애는 작업이 이루어집니다.
Transport 층은 데이터를 전송하거나, 전송받은 데이터를 합산해 Session 계층으로 보내줍니다.
Network 층은 전송 데이터를 목적지 까지 경로를 찾고 전송을 합니다. IP를 정하고, 경로를 선택하고, 패킷을 전달하는 것이 핵심인 층입니다.
Data Link 층은 물리적 네트워크 사이 Data 전송을 담당합니다.
Physical 층은 0과 1로 구분되는 비트스트림을 전송하는 계층입니다.
최상위부터 Application, Transport, Internet, Network Access 층으로 구성되어 있습니다.
Application 층은 OSI 7 계층에서 Application Presentation Session 계층의 역할을 담당합니다.
Transport 층은 동일하게 최종적인 통신 목적지를 지정하고, 오류없이 데이터를 전달하는 역할을 합니다.
Internet 층은 아래 계층의 도움을 받아, 데이터를 종단 시스템까지 전달하는 역할을 합니다.
Network Access 층은 물리적 네트워크를 통한 실제적인 데이터 전송을 담당합니다.
웹사이트의 IP 주소와 도메인 주소를 이어주는 서버입니다.
도메인 주소를 웹브라우저에 입력하면 적절한 DNS에 요청을 보내 목표에 대한 IP주소를 얻어 옵니다.
사용자가 Naver.com을 검색하면, 먼저 DNS 서버로 도메인 주소가 전달이 됩니다.
그리고 서버 내부에서 도메인 주소를 기반으로 정해진 IP주소를 찾아냅니다.
찾아낸 IP주소를 사용자, 브라우저에게 전달해 주고,
브라우저가 다시 IP주소로 접속해서 웹사이트의 데이터를 받아옵니다.
두개의 컴퓨터 사이의 직접적인 연결을 의미합니다.
P2P 연결은 두 컴퓨터의 NIC 카드에 케이블을 연결하는 것 외에 다른 네트워크 장치가 필요하지 않습니다.
TCP는 연결형 서비스를 지원하는 프로토콜로써, 호스트간 신뢰성 있는 데이터 전달과 흐름 제어를 보장합니다.
데이터 송수신에 신뢰성이 중요한 환경에서 사용됩니다.
UDP는 비연결형 서비스를 지원하는 프로토콜로써, 데이터를 보내는 쪽에서 일방적으로 데이터를 전달하며, 따로 흐름이나 오류제어를 하지 않습니다.
따라서 UDP는 전송속도가 비교적 빨라 실시간 스트리밍에서 주로 사용합니다.
여섯 개의 플래그 비트를 비롯해 많은 필드가 사용됩니다.
송신포트와 수신 포트, 세그먼트 내 전송 순서, 응답 번호, 데이터 옵셋, 체크섬 등의 필드가 존재합니다.
송신포트와 수신포트는 TCP로 연결되는 가상회선 양단의 송수신 프로세스에 할당된 네트워크 주소를 의미합니다.
전송 순서는 세그먼트 전송 과정에서 전송되는 세그먼트의 차례를 의미합니다.
응답 번호는 수신 프로세스가 제대로 수신한 바이트의 수를 응답하기 위해 사용됩니다.
데이터 옵셋은 TCP 세그먼트가 시작되는 위치를 기준으로 데이터의 시작 위치를 나타내므로, 헤더의 크기와 동일합니다.
체크섬은 TCP 세그먼트에 포함되는 프로토콜 헤터와 데이터 모두에 대한 오류 검출을 위해 사용됩니다.
Maximum transmission unit으로 TCP/IP Network와 같이 Packet 또는 Frame 기반의 Network에서 전송될 수 있는
최대 크기의 Packet 또는 Frame을 의미합니다.
매체에 따라서 MTU의 크기가 달라질 수 있습니다.
3-way hand shake: 연결을 위한 과정
1. A가 B에게 연결 요청 메세지 전송.
2. B가 정상적으로 요청 수락시, B가 A에게 포트 개방 요청 메세지 전송.
3. A가 수락 확인 메세지를 B에게 보내면 연결이 완성.
4-way hand shake: 연결 종료를 위한 과정
1. A가 B에게 연결을 종료하겠다는 FIN 메세지 전송.
2. B는 확인 메세지를 보내고 통신 종료시 까지 대기 (데이터 전송 등)
3. B가 남은 데이터 전송이 완료되었으면, 연결종료에 합의하는 FIN 메세지 전송.
4. A가 B에게 확인 메세지를 보내 연결 종료.
Hypertext Transfer Protocol 로 현재 웹을 위해 사용되는 중요한 통신 프로토콜입니다.
인터넷 상에서 데이터를 조고 받기 위한 서버/클라이언트 모델을 따르고, TCP/IP 위에서 작동합니다.
클라이언트가 요청을 보내면 서버는 요청을 처리해서 응답하는 방식으로 동작을 합니다.
기본적으로 Connectless 방식으로 작동하기 때문에, 하나의 요청에 하나의 응답을 받으면 연결이 끊어집니다.
따라서 클라이언트의 이전상태를 알 수 없는 stateless라는 특성을 가집니다. 이러한 부분을 보완하기 위해 cookie를 사용하고 있습니다.
S: Secure Socket
HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜입니다.
공개키/개인키 암호화 방식을 이용해 데이터를 암호화합니다.
클라이언트는 공개키를 얻어, 데이터를 암호화해 서버로 전송합니다.
서버는 개인키를 이용해 이를 보호화 하기 때문에 보안성이 높아집니다.
반대로 서버가 데이터를 제공하는 경우 개인키로 암호화를 합니다.
이때 공개키는 모두에게 공개되어 있으므로 공개키를 가진 사용자는 모두 데이터를 확인할 수 있습니다.
클라이언트는 공개키를 얻어, 데이터를 암호화해 서버로 전송합니다.
서버는 개인키를 이용해 이를 보호화 하기 때문에 보안성이 높아집니다.
반대로 서버가 데이터를 제공하는 경우 개인키로 암호화를 합니다.
이때 공개키는 모두에게 공개되어 있으므로 공개키를 가진 사용자는 모두 데이터를 확인할 수 있습니다.
HTTP 1.0에서는 open/close를 위한 flow의 제한으로 대역폭이 적게 할당되어 연결되는데,
이로 인해 congestion information이 자주 발생하고 disconnect가 반복적으로 나타나게 된다.
반복되는 disconnect 현상으로 인해 한 서버에 계속해서 접속을 시도하게 되면 과부하가 걸리고 성능이 떨어지게 되는 문제가 발생했습니다.
이런 문제를 해결하기 위해 HTTP 1.1이 등장했습니다.
cache를 두어 인터넷 프로토콜 수행이 빠르게 될 수 있도록 성능을 향상시켰고, multiple request에 대한 처리가 가능하도록 하였습니다.
또한, request/response가 파이프라인 방식으로 진행되어 네트워크 지연시간을 완화했습니다.
HTTP 1.1의 성능 향상에 초점을 맞춘 프로토콜입니다.
한 커넥션으로 동시에 여러 개의 메시지를 송수신할 수 있도록 개선했습니다.
또한, 웹페이지에서 CSS보다 이미지가 늦게 수신되는 경우 브라우저의 렌더링이 늦어지는 문제가 발생하는데,
리소스간 의존관계를 설정해 이러한 부분을 보완하였습니다.
그리고 HTML 문서에 포함된 리소스를 클라이언트가 요청하지 않아도, Push해주는 방법을 사용해 클라이언트의 요청을 최소화하였습니다.
요청 및 응답 메시지 모두에서 사용이 가능한 일반 목적의 General Header,
콘텐츠, 본문, 리소스 와 같은 Entity에 대한 설명이 있는 Entity 관련 Header,
요청을 위해 host, 클라이언트 정보 등을 포함하는 Request Header,
응답을 위해 서버정보, 리소스 유효기간 등을 포함하는 Response Header,
마지막으로 캐싱과 쿠기에 대한 정보를 나타내는 Header로 구성되어있습니다.
Keep Alive란 연결된 socket에 IN/OUT의 access가 마지막으로 종료된 시점부터 정의된 시간까지 access가 없더라도 대기하는 구조입니다.
즉 정의된 시간내에 access가 이루어진다면 계속 연결된 상태를 유지할 수 있습니다.
GET은 Idempotent 특징을 가지고, POST는 Non-Idempotent 특징을 가지도록 설계되었습니다.
Idempotent는 동일한 연산에 대해 항상 같은 결과가 나오는 것을 의미합니다.
즉 GET은 서버의 데이터나 상태를 변경시키지 않습니다. 그렇기 때문에 주로 조회 용도로 사용됩니다.
반대로 POST는 같은 요청에 대해 응답이 항상 다를 수 있습니다. 따라서 POST는 서버의 상태나 데이터를 변경시키는 용도로 사용될 수 있습니다.
+a
GET은 서버로부터 정보를 조회하기 위해 설계된 방법입니다.
GET은 요청을 전송할 때 필요한 데이터를 Body에 담지 않고, URL 끝에 명시하는 쿼리스트링을 활용합니다.
POST는 리소스를 생성/변경하기 위해 설계되었기 때문에, GET과 다르게 전송해야될 데이터를 HTTP body에 담아서 전송합니다.
길이에 제한이 없고, 보안성이 높다는 장점이 있습니다.
쿠키는 클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터입니다.
사용자 인증이 유효한 시간을 명시할 수 있어, 브라우저가 종료되어도 인증이 계속 유지된다는 특징이 있습니다.
사이트에 로그인 하기 위해, 아이디-비밀번호를 저장하거나, 쇼핑몰 장바구니 기능에 활용할 수 있습니다.
세션은 쿠키와 유사하지만, 정보가 로컬이 아닌 서버에 저장이 되고 관리됩니다.
서버는 클라이언트 구분하기 위해 세션 ID를 부여하고, 브라우저를 종료할 때까지 인증상태를 유지합니다.
쿠키에 비해 보안성이 높아, 로그인과 같은 보안상 중요한 작업을 할 때 사용됩니다.
1. 웹 브라우저가 https://www.google.com/images/google.png로 이미지를 요청 해야 한 다는 것을 인지 한다.
2. 웹 브라우저는 url을 이용해 서버의 ip를 추출한다.
3. 이미지를 요청하기 위한 HTTP 메세지를 만든다.
4. 메세지는 get메서드이고 /google.png를 요청하는 메세지이다.
5. 웹브라우저는 서버와 TCP 컨넥션을 맺는다.
6. 웹브라우저는 서버에 HTTP요청을 보낸다.
7. 서버는 메세지를 받고 무슨 내용인지 해석한다. get이라는 메서드이고 /google.png라는 파일을 요청 했다는 것을 인지한다.
8. 서버는 해당 리소스가 있는지 찾는다.
9. 찾으면 상태코드가 200인 메세지와 함께 응답 메세지를 작성한다.
10. 서버는 클라이언트와 TCP컨넥션을 맺는다.
11. 서버는 클라이언트에 HTTP 응답을 보낸다.
12. 커넥션이 닫히면 웹브라우저는 사용자에게 이미지를 보여준다.
웹 서버는 정적인 데이터를 처리합니다.
이미지나 단순 HTML 파일과 같은 리소스를 제공하는 서버를 웹서버를 활용하면 WAS에 비해 빠르고 안정적입니다.
WAS는 동적인 데이터를 처리합니다. DB와 연결이 필요하거나 데이터 조작이 필요한 경우 WAS를 활용합니다.
WAS는 웹 컨테이너를 통해 동적 데이터를 처리합니다. JSP나 Servlet와 같은 것을 실행하기 위한 환경을 제공해 줍니다.
* Cross-Origin Resource Sharing
HTTP 헤더를 사용해서 애플리케이션이 다른 Origin의 리소스에 접근하 수 있도록 하는 메커니즘을 말합니다.
만약 자신이 서비스하고 있지 않은 사이트에서 세션을 요청해 세션을 획득할 수 있다면,
해당 사이트에서 세션을 탈취하거나 하는 보안상 이슈가 생길 수 있기 때문에,
이러한 상황에서 허용한 Origin들만 요청할 수 있도록 만들기 위해 CORS가 필요합니다.
REST는 웹의 장점을 최대한 활용하기 위한 설계 방법입니다.
웹을 이루는 자원들이 독립적인 인터페이스를 가져야 한다는 기본 원칙을 따릅니다.
0. Self-descritive messages: 타입과, data path 명시, MIME type에 맞추어 스스로 표현
1. HATEOAS 구조: 하이퍼링크에 따라 다른 페이지를 보여주어야함, 데이터 마다 어떤 URL을 원하는지 명시
2. Stateless: API를 제공하는 서버가 Session을 유지하지 않음
3. Cacheble: 한번 받아온 데이터는 로컬에서 재로딩
4. Cilent-Server 구조: 두개가 서로 독립적, 서로의 변화가 서로에 영향 X
5. Layered system
6가지 원칙을 모두 만족하는 API를 Restful API라고 부릅니다.
API Gateway는 API 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화 해주는 또 다른 서버입니다.
API에 대한 인증과 인가 기능을 가지고 있으며, 메세지의 내용에 따라 어플리케이션 내부에 있는 마이크로서비스로 라우팅하는 역할을 담당합니다.
