웹 동작 방식
- 사용자가 브라우저에 URL을 입력
- 브라우저는 DNS를 통해 서버의 진짜 주소를 찾음
- HTTP 프로토콜을 사용하여 HTTP 요청 메세지를 생성함
- TCP/IP 연결을 통해 HTTP요청이 서버로 전송됨
- 서버는 HTTP 프로토콜을 활용해 HTTP 응답 메세지를 생성함
- TCP/IP 연결을 통해 요청한 컴퓨터로 전송
- 도착한 HTTP 응답 메세지는 웹페이지 데이터로 변환되고, 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 됨
TCP
- 신뢰성 없는 인터넷을 통해 종단간에 신뢰성 네트워크를 보장할 수 있도록 하는 프로토콜이다.
- TCP 서비스는 송신자와 수신자 모두가 소켓이라고 부르는 종단점을 생성함으로써 이루어진다.
- 양방향으로 동시에 일어날 수 있는 전이중 방식이며 각 연결이 정확히 2개의 종단점을 가지고 있는 점대점 방식이다. 그래서 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.
- TCP 에서 연결 설정은 3-way handshake를 통해 행해진다.
- 흐름 제어와 혼잡 제어를 지원하며 데이터의 순서를 보장한다.
- 흐름 제어란 보내는 측과 받는 측의 데이터 처리속도 차이를 조절해서 수신자의 버퍼 오버플로우를 방지하는 것을 말한다.
- 혼잡 제어란 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지하는 것을 말한다.
- 높은 신뢰성을 보장하지만 UDP보다 속도가 느리다.
- 연속성보다 신뢰성 있는 전송이 중요할 때 사용된다. 웹 HTTP 통신, 이메일, 파일전송 등
UDP
- 데이터를 데이터그램(독립적인 관계를 지니는 패킷) 단위로 처리하는 프로토콜이다.
- 비연결형 서비스로 데이터그램 방식을 제공한다.
- 연결을 위해 할당되는 논리적인 경로가 없고 그렇기 때문에 각각의 패킷은 다른 경로로 전송되고, 각각의 패킷은 독립적인 관계를 지니게 된다.
- 흐름제어와 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송을 하지 않는다. 이 모두가 사용자 프로세스의 몫이다.
- 신뢰성이 낮지만 TCP보다 속도가 빠르다.
- 신뢰성보다는 연속성이 중요한 서비스 예를 들면 실시간 서비스에 사용된다.
- DNS에 사용된다. 어떤 호스트 네임의 IP 주소를 찾을 필요가 있는 프로그램은 DNS 서버로 호스트 네임을 포함한 UDP 패킷을 보낸다. 이 서버는 호스트의 IP 주소를 포함한 UDP 패킷으로 응답한다. 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않다. TCP를 사용하게 되면 프로토콜 오버헤드가 커진다.
| TCP | UDP |
|---|---|
| 연결지향형 프로토콜 | 비연결지향형 프로토콜 |
| 바이트 스트림을 통한 연결 | 메시지 스트림을 통한 연결 |
| 혼잡제어 흐름제어 제공 | 혼잡 제어 흐름제어 지원하지 않음 |
| 순서 보장, 상대적으로 느림 | 순서 보장하지 않고 상대적으로 빠름 |
| 신뢰성 있는 데이터 전송으로 안정적 | 데이터 전송을 보장하지 않음 |
| TCP 패킷은 세그먼트, HTTP, Email, 파일 전송에서 사용한다. | UDP 패킷은 데이터 그램, DNS, 실시간 동영상 서비스에서 사용한다. |
TCP의 3 way handshake와 4 way handshake
- TCP의 연결을 성립하고 해제하는 과정을 말한다.
- 3way handshake(연결)
- 클라이언트가 서버에게 SYN 패킷을 보낸다(sequence : x)
- 서버가 SYN(x)를 받고, 클라이언트로 받았다는 신호인 ACK와 SYN 패킷을 보낸다 (sequence: y, ACK: x+1)
- 클라이언트는 서버의 응답은 ACK(x+1)와 SYN(y) 패킷을 받고, ACK(y+1)을 서버로 보낸다.
- 4way handshake(해제)
- 클라이언트는 서버에게 연결을 종료한다는 FIN 플래그를 보낸다.
- 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보낸다.(이때 모든 데이터를 보내기 위해 CLOSE_WAIT상태가 된다)
- 데이터를 모두 보냈다면, 연결이 종료되었다는 FIN 플래그를 클라이언트에게 보낸다.
- 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보낸다.(아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다린다) 서버는 ACK를 받은 이후 소켓을 닫고 TIME_WAIT시간이 끝나면 클라이언트도 닫는다.
추가 질문
- TCP의 연결과정과 종료과정이 단계 차이가 나는 이유?
- 클라이언트가 데이터 전송을 마쳤다고 하더라도 서버는 아직 보낼 데이터가 남아있을 수 있기 때문에 일단 FIN에 대한 ACK만 보내고, 데이터를 모두 전송한 후에 자신도 FIN 메시지를 보내기 때문
- 만약 서버에서 FIN 플래그를 전송하기 전에 전송한 패킷이 라우팅 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까?
- 이러한 현상을 대비하여 클라이언트는 서버로부터 FIN플래그를 수신하더라도 일정시간동안 세션을 남겨 놓고 잉여 패킷을 기다리는 과정을 거친다 (TIME_WAIT 과정)
- 초기 sequence number인 ISN을 0부터 시작하지 않고 난수로 생성해서 설정하는 이유는?
- 커넥션을 맺을 때 사용하는 포트는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적인 넘버가 전송된다면 이전의 커넥션으로부터 오는 패킷으로 인식할 수 있다.
GET, POST
- 둘 다 HTTP 프로토콜을 이용해서 서버에 무엇인가를 요청할 때 사용하는 방식이다.
- GET 방식
- 정보를 조회(서버에서 어떤 데이터를 가져와서 보여주기 위한 용도)하기 위한 메서드이다.
- 요청하는 데이터가 HTTP Request Message의 헤더 부분에 url이 담겨서 전송된다. url 상에 ‘?’ 뒤에 데이터가 붙어 리퀘스트를 보냄.
- url이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이다.
- 보안이 필요한 데이터에 대해서는 데이터가 그대로 url에 노출되므로 GET방식은 적절하지 않다.
- POST 방식보다 빠르다.
- POST 방식
- 서버의 값이나 상태를 바꾸기 위한 용도의 메서드이다.
- 리퀘스트는 HTTP Request Message의 바디 부분에 데이터가 담겨서 전송된다.
- 데이터 크기가 GET방식보다 크고 보안면에서 낫다.
- 클라이언트 쪽에서 데이터를 인코딩하여 서버로 전송하고, 이를 받은 서버 쪽이 해당 데이터를 디코딩한다.
- 조회하기 위한 용도로 POST가 아닌 GET방식을 사용하는 이유?
- 설계 원칙에 따라 GET 방식은 서버에서 여러 번 요청을 하더라도 동일한 응답이 돌아와야 한다.
- 웹에서 모든 리소스는 Link할 수 있는 URPL을 가지고 있어야 한다.
공인IP, 사설IP
- 공인 IP
- 전세계에서 유일한 IP로 ISP(인터넷 서비스 공급자)가 제공하는 IP주소
- 외부에 공개되어 있기 때문에 인터넷에 연결된 다른 장비로부터 접근이 가능
- 그에 따라 방화벽 등과 같은 보안 설정 필요
- 사설 IP
- 어떤 네트워크 안에서 사용되는 IP주소
- IPv4의 부족으로 인해 모든 네트워크가 공인 IP를 사용하는 것이 불가능하기 때문에 네트워크 안에서 라우터를 통해 할당받는 가상의 주소
- 별도의 설정 없이는 외부에서 접근이 불가능
OSI 7계층
- 7 계층(응용 계층): 사용자와 직접 상호작용하는 응용 프로그램들이 포함된 계층
- 6 계층(표현 계층): 데이터의 형식(Format)을 정의하는 계층
- 5 계층(세션 계층): 컴퓨터끼리 통신을 하기 위해 세션을 만드는 계층
- 4 계층(전송 계층): 최종 수신 프로세스로 데이터의 전송을 담당하는 계층
- 3 계층(네트워크 계층): 패킷을 목적지까지 가장 빠른 길로 전송하기 위한 계층
- 2 계층(데이터링크 계층): 데이터의 물리적인 전송과 에러 검출, 흐름 제어를 담당하는 계층
- 1 계층(물리 계층): 데이터를 전기 신호로 바꾸어주는 계층
HTTP, HTTPS
- HTTP
- 인터넷 상에서 클라이언트와 서버가 자원을 주고받을 때 쓰는 통신 규약이다.
- HTTP는 평문 통신이기 때문에 도청이 가능하고 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
- 또한 완전성을 증명할 수 없기 때문에 변조도 가능하다.
- 이 세가지는 다른 암호화하지 않은 프로토콜에도 공통되는 문제점들이다.
- 즉, HTTP는 텍스트 교환이므로, 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 이슈가 존재한다.
- 이런 보안 문제를 해결해주는 프로토콜이 HTTPS이다.
- HTTPS
- HTTP에 암호화된 인증, 그리고 완전성 보호를 더한 것이다.
- HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security) 라는 프로토콜로 대체하는 것이다.
- HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.
- SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다. (공개키 암호화 방식)
- 모든 웹 페이지에서 HTTPS를 사용해도 될까?
- 평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다.
- 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대 당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.
- 하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다.
- 따라서 웹은 과거의 민감한 정보를 다룰때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.
쿠키, 세션
- 쿠키와 세션의 사용이유
- HTTP 프로토콜은 클라이언트가 요청을 서버에 보내고 서버가 클라이언트에 요청에 맞는 응답을 보내면 바로 연결을 끊는다.(비연결 지향)
- 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다.(상태정보 유지 안함)
- 이와 같은 특징으로 모든 요청 간의 의존관계가 없다. 즉, 현재 접속한 사용자가 이전에 접속했던 사용자와 같은 사용자인지 알 수 있는 방법이 없다.
- 계속해서 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것이 큰 장점이지만, 통신할 때마다 새로 연결하기 때문에 클라이언트는 매 요청마다 인증을 해야 한다는 단점이 있다.
- 이전 요청과 현재 요청이 같은 사용자의 요청인지 알기 위해서는 상태를 유지해야 한다. HTTP 프로토콜에서 상태를 유지하기 위한 기술로 쿠키와 세션이 있다.
쿠키
- 클라이언트 로컬에 저장되는 키와 값이 들어있는 파일이다.
- 이름, 값, 유효 시간, 경로 등을 포함하고 있다.
- 클라이언트의 상태 정보를 브라우저에 저장하여 참조한다.
- 동작과정
- 웹브라우저가 서버에 요청하면 상태를 유지하고 싶은 값을 쿠키로 생성
- 서버가 응답할 때 HTTP 헤더에 쿠키를 포함해서 전송한다.
- 전달받은 쿠키는 웹브라우저에서 관리하고 있다가, 다음 요청 때 쿠키를 HTTP 헤더에 넣어서 전송한다.
- 서버에서는 쿠키 정보를 읽어 이전 상태 정보를 확인한 후 응답한다.
- 예시로는 아이디, 비밀번호 저장, 쇼핑몰 장바구니
세션
- 일정 시간 동안 같은 브라우저로부터 들어오는 요청을 하나의 상태로 보고 그 상태를 유지하는 기술이다.
- 즉, 웹 브라우저를 통해 서버에 접속한 이후부터 브라우저를 종료할 때까지 유지되는 상태이다.
- 동작과정
- 웹브라우저가 서버에 요청하면 서버가 해당 웹브라우저에 유일한 ID를 부여한다.
- 서버가 응답할 때 HTTP 헤더에 Session ID를 포함해서 전송한다.
- 웹브라우저는 이후 웹브라우저를 닫기까지 다음 요청 때 부여된 Session ID가 담겨있는 쿠키를 HTTP 헤더에 넣어서 전송한다.
- 서버는 세션 ID를 확인하고, 해당 세션에 관련된 정보를 확인한 후 응답한다.
- 예로는 로그인
쿠키와 세션의 차이점
- 쿠키는 클라이언트에 저장되므로 보안에 취약하다. 만료시간에 따라 브라우저를 종료해도 계속해서 남아 있을 수 있다. 클라이언트에 저장되어서 서버에 요청 시 빠르다.
- 세션은 서버에 저장되고 쿠키를 이용해 Session ID만 저장하고 이 값으로 구분해서 서버에서 처리하므로 비교적 보안성이 좋다. 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다. 실제 저장된 정보가 서버에 있으므로 서버의 처리가 필요해 쿠키보다 느리다.
REST (웹인가?)
- 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나
- HTTP URI를 통해 자원을 명시하고, HTTP Method(Post, Get, Put, Delete)를 통해 해당 자원에 대한 CRUD 연산을 적용하는 것을 의미
- 장점
- 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장
- HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져간다
- 단점
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다
- 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재(PUT, DELETE 사용 못하는점, pushState를 지원하지 않는 점)
- 필요한 이유
- 애플리케이션 분리 및 통합
- 다양한 클라이언트의 등장
- 즉, 최근의 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다
REST API
RESTful
CORS(Cross Origin Resource Sharing)
DNS
소켓
프록시 서버
VPN
혼자 공부하면서 정리하는 블로그
0개의 댓글
관련 채용 정보
