HTTP
클라이언트와 서버 사이에 이뤄지는 요청과 응답 데이터를 전송하는 방식
HTTP 프로토콜
- 하이퍼 텍스트 기반의 통신 규약으로 브라우저 상에서 데이터 교환 시 사용하는 프로토콜
- 클라이언트가 서버에 연결한 후 클라이언트의 요청에 대해 서버가 응답을 마치고 연결을 끊어버림
- 이러한 성질 때문에 서버는 클라이언트를 식별할 수 없고, 이러한 성질을 stateless 라고 함
- stateless를 보완하기 위해 쿠키, 세션, 토큰을 통해 웹 사이트의 상태를 기억
HTTP 메소드의 종류
- GET : 리소스 조회 시 사용, 서버에 데이터를 전달하는 경우 쿼리스트링을 통해 전달
- POST : 요청한 데이터를 등록하는 경우에 사용, 메시지 바디를 통해 서버로 요청 데이터를 전달, 서버는 요청 데이터 처리
- PUT : 리소스를 수정하는 메서드로, 요청 메시지에 리소스가 있으면 덮어쓰고, 없으면 새로 생성 , 일부 리소스를 변경하려는 경우 기존 데이터를 완전히 대체해 이름 데이터가 삭제됨
- PATCH : 리소스 일부분을 변경하는 메소드
- DELETE : 리소스를 제거하는 메소드
HTTP vs HTTPS
- HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜
- HTTP는 별도의 암호화, 복호화 과정이 필요 없기 때문에 속도가 빠르다
- HTTPS는 SSL 프로토콜 위에서 구동되며 데이터 암호화가 추가된 프로토콜
- HTTPS는 443포트를 통해 네트워크 중간에서 다른사람이 정보를 탈취할 수 없도록 암호화 지원
- 처음 연결 후 세션키를 공유하는 경우 비대칭키 사용, 데이터 교환시 대칭 키 사용
HTTP status code
- 1xx : 요청 후 정보를 전달 하는 상태코드
- 100 : 현재까지의 진행상태의 문제가 없음을 의미하는 응답코드- 101 : websocket 프로토콜 전환 시 사용
- 2xx : 요청을 받고 성공적으로 응답했다는 상태코드
- 200 : 요청이 성공적으로 되고, 응답 반환- 201 : 요청이 성공적이고, 리소스가 생성됨. POST, PUT 요청 이후에 따라옴
- 204 : 요청에 대해서 전송할 콘텐츠 없고, 리소스가 캐시된 헤더를 새로운 것으로 업데이트
- 3xx : 요청을 받고 리다이렉션 하는 코드
- 301 : 요청한 리소스의 URI가 변경됬음을 알리는 코드- 302 : 요청한 리소스의 URI이 일시적으로 변경되었음을 의미
- 4xx : 클라이언트에서 발생하는 오류로 요청을 처리할 수 없는 경우 반환되는 상태코드
- 400 : 잘못된 문법으로 서버에 요청할 수 없는 코드- 401 : 클라이언트가 인증이 되지 않는 경우
- 404 : 서버가 요청받은 리소스를 찾을 수 없는 경우 반환
- 5xx : 서버가 요청에 대한 응답을 줄 수 없는 경우 발생하는 상태코드
- 500 : 서버에 오류가 발생하여 요청을 수행할 수 없는 경우- 502 : 서버위의 서버에서 오류가 발생하는 경우, 프록시나 게이트웨이 등에서 응답함
- 503 : 서버가 일시적으로 사용이 불가한 경우
REST API
- HTTP URI를 통해 자원을 표현하고, HTTP Method를 통해 해당 자원에 대한 CRUD 을 적용한 API
- 특징
- 클라이언트의 context를 별도로 server에 저장하지 않음
- HTTP 프로토콜에서 사용하는 캐싱 기능을 적용할 수 있다
- URI로 지정한 자원에 대한 조작은 통일되고 한정적인 인터페이스로 수행
- 설계 규칙
- 슬래시 구분자는 계층관계를 나타냄
- URI 마지막 문자로 슬래시 포함하지 않는다
- 하이픈은 URI 가독성을 높이는데 사용한다
- 장점
- 범용성을 보장
- REST API 사용을 위한 별도의 인프라 구축 필요 x
- 서버 - 클라이언트 분리
- 단점
- HTTP Method 가 제한적
- 표준이 존재하지 않음
- 특징
CORS
- 현재 서버가 아닌 다른 URL의 리소스 공유에 대한 허용/비허용 정책
- 동작과정
1. 클라이언트에서 HTTP 요청의 헤더에 Origin과 접근하려는 URL을 담아 전달
2. 서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달
3. 클라이언트에서 Origin과 서버가 보내준 Access-Control-Allow-Origin 비교 후 차단 여부를 결정
웹 서버 vs 웹 어플리케이션 서버
웹 서버
- http 프로토콜을 기반으로 하여 클라이언트의 요청을 서비스하는 기능을 담당하는 서버
- was(웹 서버)가 처리한 결과를 클라이언트에게 전달하는 경우에도 사용
- 어플리케이션 서버까지 가지 않고 클라이언트에서 정적파일을 빠르게 보내주기 때문에 서버의 부담을 줄이는 장점이 있다
웹 어플리케이션 서버
- db나 동적인 컨텐츠를 제공하기 위해 만들어진 어플리케이션 서버
- 분산 트랜잭션, 보안, 스레드 처리 등의 기능을 처리하는 분산 환경에서 사용됨
- 웹서버만 사용하는 경우엔 컨텐츠를 미리 생성해야 하는데 이런 경우엔 자원이 절대적으로 부족하기 때문에 was를 통해 요청에 맞는 데이터를 가져와서 결과를 제공하므로써 자원을 효율적으로 사용할 수 있다
쿠키 vs 세션
쿠키
- 클라이언트에 저장되는 상태 정보 파일
- http에서 클라이언트 pc에 저장했다가 필요시 정보를 참조하거나 재 사용할 수 있음
- 로컬에 저장되기 때문에 보안에 취약
- 만료기간을 지정해 쿠키를 삭제할 때 까지 유지할 수 있음
- 속도 면에서 쿠키가 우수
- 쿠키의 사용 예시
- 로그인 시 아이디 저장
- 팝업창에서 다시보지 않기 체크하는 경우
세션
- 브라우저에 접속한 시점부터 종료하는 시점까지 상태가 유지되는 단위로 서버에 정보를 저장
- 브라우저의 생성과 종료에만 유지되고 session-id만 저장하고 구분하여 서버에서 처리하기 때문에 보안성이 높음
- 세션은 정보가 서버에 있어 처리가 필요하기 때문에 속도가 빠름
JWT 토큰
- JSON Web Token의 약자로 인증에 필요한 정보를 암호화시킨 JSON 토큰
- JSON 데이터를 base64로 인코딩 하여 직렬화 한 후 토큰 내부에 위변조 방지를 위해 개인키를 통한 전자서명을 두고 있음
- 구조
header.payload.signature- Header : 토큰 유형과 서명암호화 알고리즘의 종류
- Payload : 실제 JWT를 통해서 알 수 있는 데이터가 담겨있음
- Signature : 헤더와 페이로드를 base64 인코딩 한 후 header에 명시된 해시함수를 적용하고 개인키로 서명한 전자서명이 저장되어 있음
- 작동방법
- 사용자가 로그인 요청
- 서버가 클라이언트로 부터 인증요청을 받으면 header, payload, signature를 정의하고 각각 base64로 한번 더 암호화 하여 jwt 토큰 생성 후 클라이언트에게 전달
- 클라이언트는 jwt를 로컬스토리지에 저장, api 요청 시 Authorization header에 access token을 담아서 전송
- 서버는 전달받은 jwt 토큰의 일치여부 확인 한 후 일치하면 요청한 정보 응답
- accesstoken의 시간이 만료된 경우 클라이언트는 refreshtoken를 이용해서 서버로 부터 새로운 토큰을 전달받는다
세션기반인증 vs 토큰기반인증
세션기반인증
- 서버에 저장된 세션을 통해 사용자 인증을 하는 방법
- 서버의 램이나 데이터베이스에 session을 저장하고 요청을 받으면 클라이언트의 상태를 유지한다.
- 요청이 많아지는 경우 서버에 오버헤드가 발생한다
토큰기반인증
- 인증받은 사용자에게 토큰을 발급하고, 정보접근이 필요한 요청의 경우 헤더에 토큰을 넣어 응답을 보내 사용자 인지 확인한다.
- 토큰의 데이터 길이가 길기 때문에 인증 요청이 많아지면 네트워크 부하가 심해진다.
TCP vs UDP
TCP
- 연결형 서비스로 전송순서 보장
- 주로 1:1 통신을 하므로 수신여부를 확인하므로 속도가 느림
- 3-way handshake 과정을 통해 연결 설정
- 높은 신뢰성을 보장하기 때문에 중요한 데이터를 교환하는 경우 사용
UDP
- 비연결형 서비스로 전송순서 보장안함
- 흐름제어가 없기 때문에 데이터 전송 후 별도의 수신여부 확인 안함
- 신뢰성이 떨어져 실시간성이 중요한 스트리밍에서 주로 사용
- ** 흐름제어 : 데이터 송신 쪽과 수신 쪽의 데이터 처리속도를 조절하여 수신자의 버퍼 오버플로우를 방지하는 것
3-way handshake
TCP/IP 네트워크 환경에서 서버와 클라이언트를 연결하는데 필요한 과정
동작과정
1. 클라이언트가 서버에 접속하기 위해 요청 SYN 패킷을 보냄 (SYN : 연결요청플래그)
2. 서버가 클라이언트의 요청을 수락한 후 응답 ACK 패킷 과 포트를 열어달라는 SYN 패킷을 보냄 (ACK : 응답 플래그)
3. 클라이언트가 서버에게 확인 응답으로 ACK 패킷을 보냄
4-way handshake
TCP/IP 네트워크 환경에서 서버와 클라이언트를 연결 해제 하는데 필요한 과정
동작과정
1. 클라이언트에서 서버에게 연결 종료 플래그인 FIN 패킷을 보냄
2. 서버는 클라이언트로 부터 FIN 패킷을 받고, 응답 패킷 ACK를 보냄
3. 연결을 종료할 준비가 되면 클라이언트에게 FIN 패킷을 보냄
4. 클라이언트는 연결종료 확인 후 ACK 패킷을 보냄
5. 서버와 클라이언트는 세션을 종료함
3-way handshake와 4-way handshake 동작과정에 차이가 있는 이유
-> 추후 작성 예정
connect timeout vs read timeout
connect timeout
- tcp 3way handshake를 통해 클라이언트가 서버에게 연결하는데 소요되는 최대 시간
- 설정해 놓은 시간을 넘기면 연결할 수 없다고 판단되 에러가 발생한다
read timeout
- 연결된 클라이언트와 서버간의 데이터를 주고받을 때 소요되는 최대 시간
- 데이터를 주고 받을 때 사용되는 타임아웃 시간이다
라우터 vs 스위치
라우터
- 목적지 까지의 통신 경로를 결정하기 위해 한 통신망에서 다른 통신망으로 데이터 패킷을 전송하는 장치
- 네트워크 계층에 속해 있어 IP주소를 기반으로 작동
- 테이블에 필요한 정보가 없는 경우 데이터를 파기한다
스위치
- 연결된 장치의 정보를 테이블 형태로 가지고 있고, 원하는 목적지에 데이터 패킷을 전송하는 장치
- 데이터 링크 계층에 속해 있어 MAC 주소 기반으로 동작
- 테이블에 필요한 정보가 없는 경우 데이터를 브로드캐스트 한다
DNS 서버
- 도메인 이름을 IP주소로 바꿔주는 역할을 하는 서버
- 클라이언트가 서버의 직접적인 IP를 몰라도 해당 사이트에 접근할 수 있음
OSI 7계층
네트워크에 대한 표준을 7계층으로 나눈 것
- 물리계층 : 전기적 특성을 이용해서 통신 케이블로 비트 단위의 데이터 전송
- 데이터 링크 계층 : 물리 계층의 물리적 전송 오류 문제를 해결하는 계층, 브릿지나 스위치를 통해 Mac address를 가지고 물리계층에서 받은 정보 전달
- 네트워크 계층 : 주소를 정하고 경로에 따라 패킷을 전달해주는 역할을 하는 계층
- 전송 계층 : TCP 프로토콜을 이용하여 포트를 열어 프로그램 간의 전송을 할 수 있도록 하는 계층
- 세션 계층 : 송수신자 사이에 상위적 연결 개념인 세션을 지원하는 계층. TCP/IP 세션을 만들고 없애는 책임을 진다.
- 표현 계층 : 데이터의 의미와 표현방법, 암호화/압축 기능을 처리
- 응용 계층 : HTTP, FTP, SMTP 같은 프로토콜을 지원하는 계층
TCP/IP 4계층
- TCP/IP 프로토콜 통신과정에 초점을 맞춘 계층
- 데이터 전송 시 상위계층에서 하위계층으로 이동하고 데이터는 헤더에 추가되어 전달됨
- 데이터 수신 시 하위계층에서 상위계층으로 전달되며 계층마다 헤더를 읽고, 헤더를 제거한다
- 응용계층 : 사용자와 소프트웨어 간 소통 담당하는 계층으로 HTTP, FTP, SSH, DNS, SMTP 프로토콜이 있다
- 전송계층 : 시스템에서 제공하고 통신 노드 간 신뢰성 있는 데이터 전송을 보장하는 계층으로 포트번호로 데이터를 응용계층에 전달, TCP, UDP 프로토콜이 있음
- 네트워크 계층 : 패킷을 최종 목적지 까지 라우팅 하는 계층으로 IP, ARP 프로토콜이 있음
- 네트워크 접속 계층 : 데이터를 전기신호로 변환하고 MAC 주소를 사용해 기기로 데이터를 전달하는 계층으로 이더넷, 와이파이 프로토콜이 있다
www.google.com을 주소창에 쳤을 때 화면이 나오기까지의 과정을 설명해주세요
- 클라이언트가 주소창에 url 주소를 입력
- 웹 브라우저는 캐싱된 DNS 기록들을 통해 도메인 주소와 대응하는 IP주소를 확인. IP주소가 없는 경우에는 DNS 서버로 요청을 전달
- ISP의 호스팅 서버에 DNS 쿼리를 전송해 IP주소를 응답받는다
- 웹브라우저는 서버에 IP주소를 이용하여 TCP 프로토콜을 통해 html 문서를 요청
- 웹애플리케이션서버(WAS)와 데이터베이스는 페이지에서 필요한 동적인 부분 처리를 끝내고 웹 서버로 처리 결과를 전송
- 웹 서버는 브라우저에게 html 문서 결과를 응답
- 웹 브라우저는 화면에 페이지를 출력
url 입력 후 패킷 생성 과정
- 응용계층에서 http 요청을 전달 받아 전송계층에서 시작포트번호와 목적지 포트번호를 담은 TCP 패킷의 헤더를 생성한다
- 인터넷 계층에서 시작 ip와 목적지 ip 주소를 저장한 패킷을 생성한다
- 네트워크 계층에서 시작과 목적지 mac 주소를 담은 이더넷 헤더를 생성한다
- 완성한 패킷들을 전달하기 위해 private ip를 public ip로 변환한다
- 3-way handshake를 활용해 tcp를 연결한다
- 보내는 쪽 공유기에서 많은 라우터를 거쳐 서버의 공유기로 전달한 후 패킷의 ip헤더에 적인 주소로 서버의 mac 주소를 구해 전달한다
- TCP 패킷에 적힌 목적지 포트에 패킷을 전달
- http 요청에 대한 처리를 진행한 후 처리 결과를 응답으로 전송한다
- 응답 완료 후 4-way handshake를 통해 연결을 끊는다
:)