예비 답안 보기 (👈 Click)
현대의 인터넷은 여러가지 실용성과 구현 측면에서 OSI 7계층 모델이 아닌 TCP/IP 모델을 따르고 있다. OSI 모델의 Application, Presentation, Session 계층이 TCP/IP 모델에서는 Application으로 합쳐졌다고 보면 된다.
- Application(응용) 계층 : 최종 목적지로 응용 프로그램과 연관하여 서비스를 수행하는 계층
- 최상위 계층으로 사용자와 직접 상호작용하는 프로토콜이 속함.
- ex) HTTP, FTP, DNS
- Presentation(표현) 계층 : 데이터 압축, 변환이 이뤄지는 계층
- ex) JPEG, MPEG
- Session(세션) 계층 : 데이터가 통신하기 위한 논리적 연결을 담당하는 계층
- ex) API, Socket
- Transport(전송) 계층 : 종단 간의 사용자들에게 신뢰성 있는 데이터를 전달하는 계층
- TCP / UDP 가 여기에 해당.
- 흐름 제어 : 송신측과 수신측 사이의 데이터 처리 속도 차이를 제어
- 혼잡 제어 : 네트워크 혼잡을 피하기 위해 데이터의 전송 속도 제어
- 오류 제어 : 오류 검출과 재전송
- Network(네트워크) 계층 : IP를 지정하고 라우터로 경로를 선택해 네트워크를 통해 패킷을 전달하는 계층
- Data Link(데이터링크) 계층 : 신뢰성 있는 전송을 보장하기 위한 계층
- 오류 제어, 흐름 제어, 회선 제어
- Physical(물리) 계층 : 비트 단위신호들을 전기신호로 변환하는 역할
계층을 나눈 이유 : 통신이 일어나는 과정을 단계별로 알 수 있고, 문제가 생기면 그 단계만 수정하면 된다.
예비 답안 보기 (👈 Click)
- IP주소를 문자로 표현한 주소로 바꾸는 시스템 혹은 서버
www.google.com에 접속할 때 일어나는 일
예비 답안 보기 (👈 Click)
- www.google.com을 브라우저 주소창에 입력한다.
- 브라우저는 캐싱된 DNS 기록을 통해 www.google.com에 대응되는 IP 주소가 있는지 확인한다.
- 브라우저 캐시 확인
- OS 캐시 확인
- 라우터 캐시 확인
- ISP 캐시 확인
- 요청한 URL이 캐시에 없으면 ISP(인터넷 서비스 제공자, kt 등)의 DNS 서버가 www.google.com을 호스팅하고 있는 서버의 IP 주소를 찾기 위해 DNS query를 날려서 찾는다.
- 브라우저는 IP주소를 받아 서버와 TCP 연결을 한다. (3 way handshaking)
- 클라이언트가 서버로 접속 요청 SYN 패킷을 보낸다.
- 서버에서는 수락하는 ACK와 SYN 패킷을 보낸다.
- 클라이언트는 서버에게 확인 응답으로 ACK 패킷을 보낸다.
- TCP 연결이 완료되면 브라우저가 웹 서버에 HTTP 요청을 보낸다.
- 서버는 요청을 처리하고 response를 생성하고 보낸다.
- 브라우저가 HTML content를 사용자에게 보여준다.
서버단에서 클라이언트 단으로 index.html을 응답으로 보내게 되는데 여기 안에는 구글의 이미지 google.png가 들어있다.
웹 브라우저는 html파일을 읽어서 해석하는데 이미지 주소가 나오면 다시 해당 url로 서버에 요청을 보내고 위와 같은 요청을 반복한다.
예비 답안 보기 (👈 Click)
HTTP 요청과 응답 과정이 끝나면 연결과정을 종료하는 4-way-handshaking이 진행된다.
- 클라이언트가 서버로 연결을 종료하겠다는 FIN 패킷 전송
- 서버는 클라이언트에게 우선적으로 ACK 패킷 전송
- 서버는 자신의 통신의 끝날 때까지 기다리고 끝나면 클라이언트에게 FIN 패킷 전송
- 클라이언트는 확인했다는 의미로 ACK 패킷을 서버에게 전송
- 서버가 보내는 FIN보다 서버가 보내는 데이터가 늦게 보내질 경우를 대비해 클라이언트는 일정 시간 동안 소켓을 닫지 않고 잉여 패킷을 기다림(time wait)
- 이후에 연결 종료
예비 답안 보기 (👈 Click)
Client가 데이터 전송을 마쳤다고 하더라도 Server는 아직 보낼 데이터가 남아있을 수 있기 때문에 일단 ACK만 먼저 보내고, 데이터를 모두 전송한 후에 자신도 FIN 메시지를 보내기 때문이다.
예비 답안 보기 (👈 Click)
이러한 현상을 대비하여 Client는 Server로부터 FIN 플래그를 수신하더라도 일정기간 time wait동안 세션을 남겨 놓고 잉여 패킷을 기다리는 과정을 거친다.
예비 답안 보기 (👈 Click)
- 포트
- 네트워크를 통해 데이터를 주고받는 프로세스를 식별하기 위해 호스트 내부적으로 프로세스가 할당받는 고유한 값
- 하나의 IP 주소 내에 개별적으로 부여된 통신 프로세스
- 소켓
- 네트워크상에서 동작하는 프로그램 간 통신의 종착점(Endpoint)
- 두 시스템 사이의 네트워크 연결을 나타내는 객체
- 소켓을 열기 위해선 호스트에 할당된 IP, 포트 번호, 프로토콜이 필요하다.
- 위 세가지가 소켓을 정의할 수 있지만 유일하게 식별하지는 않는다.
- 보내는 쪽과 받는 쪽 모두 소켓을 열어야 한다.
- 하나의 프로세스가 같은 포트를 갖고 여러 개의 소켓을 열 수 있다.
예비 답안 보기 (👈 Click)
사이더(Classless inter-Domain Routing, CIDR)는 직역 그대로 클래스없는 도메인간 라우팅 기법 이다.
기존 IP 주소 할당 방식이었던 클래스를 대체하며 IP주소의 네트워크 영역, 호스트영역을 유연하게 나누어준다.
서브넷 마스크는 /를 사용해서 명시한다.
예비 답안 보기 (👈 Click)
- Subnetting
- 기본의 class로 분리하는 IP 주소 체계에서, 네트워크 부분과 호스트 부분으로 IP영역대를 분리하는 것
- 분할하는 이유는 브로드캐스트에서 성능 저하가 발생하기 때문
- 네트워크 부분이 같다면 같은 네트워크에 포함되어있는 호스트이고, 네트워크 부분을 서브넷 마스크를 통해 구분한다.
- Subnet
- 특정 지역에서 관리되는 IP 영역을 몇 개의 영역으로 나눠서 관리하는 것
- 장점
- 네트워크 브로드캐스트 사이즈를 줄일 수 있다.
- 브로드캐스트 : IP 네트워크에 있는 모든 로컬 네트워크 호스트로 데이터를 전송하는 방식
- 효율적으로 관리할 수 있다.
- 네트워크 분리에 따라 보안성 향상
- 네트워크 브로드캐스트 사이즈를 줄일 수 있다.
10.0.0.0/24 로 예를 들면, 앞에 24비트(서브넷마스크) 10.0.0을 네트워크 영역 뒤에 마지막 0을 호스트 영역이라고 한다. 앞의 24비트는 네트워크 영역으로 같다면 같은 네트워크 대역이다. 뒤쪽의 8비트는 호스트 영역 범위인데 해당 10.0.0 네트워크에 호스트 영역으로 2^8개의 범위, 즉 2^8개의 Ip를 범위를 할당한다는 것이다. 여기서 8은 32비트 - 24비트로 나온 것이다.
여기서 4개의 서브넷으로 쪼갠다고 한다면 마지막 8비트의 맨앞 2자리를 서브넷으로 구분하는데 사용한다. 2자리를 사용하는 이유는 2^n>=4 일때 n는 2가 최소값이기 때문이다. 만약 5개의 서브넷으로 쪼갠다면 앞에 3비트를 써야한다.
4개의 서브넷으로 쪼갠다면 8비트의 맨앞 2자리가 00, 01, 10, 11로 구분되어 2자리가 서브넷 ID가 되고 나머지 뒤에 6자리가 사용가능한 호스트 ID가 된다.
예비 답안 보기 (👈 Click)
- TCP
- 연결형 서비스를 지원하는 전송계층 프로토콜
- 연속성보다 신뢰성있는 전송이 중요할 때에 사용하는 프로토콜
- 인터넷 환경(http)에서 기본으로 사용
- 초기화(3way-hand-shaking)과 종료(4way-hand-shaking) 필요
- 흐름 제어(송수신 측의 데이터 처리 속도차이 해결), 혼잡 제어(송신측의 전달과 네트워크 데이터 처리 속도 해결), 오류 제어(오류 검출과 재전송)를 통해 신뢰성을 보장
- 전이중, 점대점 방식이다.
- 전이중 : 전송이 양방향으로 동시에 일어날 수 있다.
- 점대점 : 각 연결이 정확히 2개의 종단점을 가지고 있다.
- 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.
- UDP
- 비연결성 서비스를 지원하는 전송 프로토콜
- 신뢰성보다 연속성이 중요할 때 사용하는 프로토콜
- 신뢰성이 낮지만 속도가 빠르다.(스트리밍 서비스에 이용)
- checksum 필드를 통해 최소한의 오류만 검출한다.
- 전송을 위한 논리적인 경로가 없다.
- 전송 순서를 보장하지 않음
- 수신 여부를 확인하지 않음
- 참고
- UDP와 TCP는 각각 별도의 포트 주소 공간을 관리하므로 같은 포트 번호를 사용해도 무방하다.
- 즉, 두 프로토콜에서 동일한 포트 번호를 할당해도 서로 다른 포트로 간주한다.
- Checksum은 헤더와 데이터의 에러 확인 용도로 사용되나 UDP는 에러 복구를 위한 필드가 불필요하기 때문에 TCP 헤더에 비해 간단하다.
예비 답안 보기 (👈 Click)
- HTTP 프로토콜의 특징
- 비연결 지향(connectionless) : 클라이언트가 request를 서버에 보내고, 서버가 클라이언트에 요청에 맞는 response를 보내면 바로 연결을 끊는다.
- 상태 정보 유지 안 함(stateless) : 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다.
- HTTP
- www 상에서 정보를 주고받을 수 있는 포로토콜
- 80번 포트 사용
- 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜
- 주로 HTML 문서를 주고 받는데 사용
- TCP(HTTP/1, HTTP/2), UDP(HTTP/3)를 사용
- HTTPS
- HTTP의 보안상 문제를 해결하기 위해 등장한 프로토콜
- HTTP는 텍스트로 자원을 주고받기 때문에 네트워크를 가로챈다면 내용이 유출되는 보안 이슈가 발생한다.
- SSL, TLS(SSL의 최신 버전)를 이용해 암호화하여 주고받음
- 응용 계층 및 전송 계층 사이에 위치
- 443 포트 사용
- 모든 HTTP 요청과 응답 데이터는 네트워크로 보내기지 전에 전송 계층과 응용 계층 사이에서 암호화 된다.
- HTTP 자체를 암호화하는 것이 아니라 운반하는 HTTP Body 부만 암호화를 진행하고 Header는 암호화하지 않는다.
- 암호화 통신 방법 (공개키/개인키, 대칭키 방식을 혼합해서 사용)
- A에서 B로 접속 요청
- B에서 공개키를 A에게 전달
- A는 자신의 대칭키를 공개키 A로 암호화해서 B에게 전달
- B는 개인키로 복호화하여 A의 대칭키를 얻음
- 얻어낸 대칭키를 이용하여 A와 B가 암호문을 주고 받음
- 단점
- 암호화 추가 비용 발생
- 암호화 과정에서 웹 서버에 부하
- 연결이 끊기면 재인증 시간이 소요
예비 답안 보기 (👈 Click)
- GET
- 조회, 리소스 요청
- POST
- 요청된 데이터 처리
- 자원을 생성
- PUT
- 요청된 자원이 없으면 생성
- 요청된 자원을 새 것으로 전체 갱신
- PATCH
- 자원의 일부분만 수정
- DELETE
- 요청된 자원 삭제
예비 답안 보기 (👈 Click)
웹 브라우저는 3XX 응답 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)한다.
- 3xx
- 영구 리다이렉션
- 301 Moved Permanently : 리소스의 URL이 원래 URL를 사용하지 않고 영구적으로 이동
- 308 Permanent Redirect : 301과 같은 기능이지만 리다이렉트 시점에 메서드와 본문이 유지
- 일시적 리다이렉션
- 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음
- 307 Temporary Redirect : 302와 같은 기능이지만 리다이렉트 시 요청 메서드와 본문 유지
- 304 Not Modified
- 캐시를 목적으로 사용
- 클라이언트에게 리소스가 수정되지 않았음을 알려줘 클라이언트는 로컬 PC에 저장된 캐시를 재사용
- 응답에 메시디 바디를 포함하면 안된다(로컬 캐시를 사용해야 하기 때문)
- 조건부 GET, HEAD 요청시 사용
- 영구 리다이렉션
- 4xx
- 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서바가 요청 처리 불가
- 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 되지 않아 인증이 필요
- 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부, 주로 인증 자격 증명은 있지만 접근 권한이 불분명한 경우
- 404 Not Found : 요청 리소스를 서버에서 찾을 수 없음
301 영구 리다이렉션의 경우, 말그대로 요청한 정보(사이트나 페이지)가 영구적으로 옮겨져 다시는 돌아오지 않을 것임을 말해준다. 이말은 새로운 URL로 영원히(Permanently) 이동되었으니, 검색 엔진은 기존 URL에 대한 사이트 랭크와 평가점수와 같은 모든 SEO 값과 링크 리소스를 New URL 로 이전하며, 페이지에 대한 정보도 New URL 페이지만을 수집하게 된다. 영구 리다이렉트를 적용하면, 포털 검색에 이전 URL을 없애주고 새 URL을 표시하게 해주며, 링크 신호를 통합해주기 때문에 이전 URL의 백링크들을 새 URL를 직접 가리키는 것처럼 통합시켜 준다.
302 일시 리다이렉션의 경우, 말그대로 요청한 정보(사이트나 페이지)가 일시(임시)적으로 옮겼다는 것을 말해준다. 즉, 언제든지 이전 URL로 다시 돌아올수 있다는 말이다. 301과 대조적으로 302는 일시적으로(Temporarily) 새로운 URL로 이동했음을 나타내기 때문에, 그래서 검색 엔진은 사이트 랭크와 평가점수와 같은 모든 SEO 값과 링크 리소스를 옮기지 않고 유지하며, 컨텐츠만 New URL에서 조회하도록 한다. 그리고 리다이렉트 했음에도 여전히 Old URL 페이지에 대한 정보를 수집한다.
정리하면, 301 리다이렉트는 모든 평가(링크 권위, 검색 순위 등)를 새로운 URL로 옮기며 영구적인 리다이렉트로 브라우저에 캐싱될 수 있다. 반면, 302 리다이렉트는 임시적이며 평가를 옮기지 않고, 서버 로직에 의해 상태가 자주 변경되는 경우에 적합하다.
예비 답안 보기 (👈 Click)
특정 HTTP 메서드를 여러 번 요청을 했을 경우, 매번 요청 결과가 같다면 해당 메소드를 멱등성 메소드라고 한다.
GET, PUT, DELETE가 멱등성 메서드에 속하고 POST는 멱등성 메서드가 아니다.
같은 POST를 연속적으로 보낸다면 명령은 여러 번 내린 것처럼 부가적인 결과를 가져오기 때문이다.(POST 요청을 반복하면 같은 내용이더라도 다른 데이터가 계속 추가된다.)
GET은 여러 번 수행해도 서버의 상태가 변하지도 않고 같은 결과를 가져온다.
PUT은 여러 번 수행해도 결과적으로 데이터는 요청한 값으로 수정된 항상 같은 상태이다.
DELETE도 여러 번 수행해도 이미 존재하든, 존재하지 않든 그 데이터는 DELETE 요청을 보낸 시점에 사라진다.
cf 안전성
안전성은 호출해도 리소스를 변경하지 않는 특성으로 서버에 영향을 끼치는 여부로 생각하면 된다.
GET 메서드만 안전성 메서드다.
예비 답안 보기 (👈 Click)
HTTP는 매번 연결을 끊고 새로 생성한다.
특정 시간까지는 access가 없더라도 기다리고 연결상태를 유지하는 헤더이다.
HTTP 1.1부터는 defualt로 keep-alive를 지원한다.
예비 답안 보기 (👈 Click)
- HTTP 1.0
- 요청 컨텐츠마다 TCP 커넥션을 맺고 끊음을 반복한다.
- 요청1 -> 응답1 -> 요청2 -> 응답2 순으로 순차적으로 진행된다. 즉, 응답을 받아야만 다음 작업을 한다.
- HTTP 1.1
- 매 요청마다 TCP 커넥션을 맺고 끊음을 반복하지 않고 keep-alive를 통해 일정 시간 동안 커넥션을 유지한다.
- 클라이언트는 각 요청에 대한 응답을 기다리지 않고 여러개의 요청을 연속적으로 보낸다.(파이프라이닝) 하지만 각 응답의 처리는 순차적으로 처리된다.
cf) 파이프라이닝
예비 답안 보기 (👈 Click)
- 하나의 커넥션으로 동시에 여러 개의 메세지를 주고 받을 수 있으며, response는 순서에 상관없이 stream으로 주고받는다.
- 서버는 클라이언트의 요청에 대해 요청하지 않은 리소스를 마음대로 보낼 수 있다.
- Header의 내용과 중복되는 필드를 재전송하지 않아 데이터를 절약한다.
HTTP/2.0은 한 커넥션에서 여러개의 메시지를 주고받을 수 있으며, 응답은 순서에 상관없이 stream으로 주고받는다.
위 그림을 보면 하나의 커넥션에서 여러 병렬 스트림(3개)가 존재한다. Stream이 뒤섞여서 전송될 경우, 수신측에서 stream number을 이용해 재조합한다.
서버는 클라이언트 요청에 대해 요청하지 않은 리소스도 보낼 수 있다.
HTTP/1.1에서는 HTML문서를 요청하고 받은뒤 그 안에 css,image 파일이 있다면 서버로 재요청했으나, HTTP/2.0에서는 Server Push 기능으로 클라이언트에서 요청하지 않은 (HTML문서에 포함된 리소스) 리소스를 Push 해주는 방법으로 클라이언트의 요청을 최소화하여 성능을 향상시킨다.
Header의 내용과 중복되는 필드를 재전송하지 않도록 하여, 데이터를 절약한다.
기존에 HTTP Header가 Plain Text(평문)이었지만, HTTP/2에서는 Hash Table과 Huffman Coding을 사용하는 HPACK이라는 Header 압축방식을 이용하여 데이터 전송 효율을 높였다.
예비 답안 보기 (👈 Click)
교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.
웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다.
브라우저는 보안상의 이유로, 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다.
예를 들면, domain-a.com <-> domain-b.com 간의 요청은 CORS정책 위반으로, 브라우저에서 요청을 제한한다.
따라서 다른 출처의 리소스를 불러오기 위해서는, 그 출처에서 교차 출처 리소스 공유에 대한 헤더(CORS)를 응답 시 반환해주어야 한다. 기본적으로는 다음과 같이 동작한다.
- 실제 요청을 보내기 전에 Preflight라는 예비 요청을 보낸다. 이때 HTTP의 OPTIONS 메서드를 이용해 서버에 보낸다.
- 서버는 예비 요청이 CORS를 위반하고 있는지를 확인하고 정보를 클라이언트에게 보낸다.
- Preflight에 대해 서버 응답이 안전하다면 실제 요청을 보낸다.
예비 답안 보기 (👈 Click)
REST는 HTTP URI를 통해 자원을 명시하고 HTTP Method를 통해 자원을 처리하도록 설계된 아키텍처이다.
REST를 기반으로 만든 API를 REST API라고 한다.
RESTful은 REST 아키텍처를 구현하는 웹서비스를 나타내는 것으로 REST 원리를 따르는 시스템을 RESTful이라고 한다.
HATEOAS라는 개념이 있는데, 동적인 API를 제공할 수 있게 된다.
모든 관련된 동작 을 URI를 통해 알려주어, 클라이언트가 API의 변화에 일일이 대응하지 않아도 된다는 장점이 있다.
HTTP를 기반으로 동작하다보니 HTTP의 이점을 그대로 가져올 수 있다.(무상태, 캐시처리 등등..)
- HTTP Method를 한가지만 사용하고 있다.(Post만 사용하고 있다던가)
- URL에 동사를 사용하고 있다.(리소스는 명사적 특성을 갖는다.)
정리하면, HTTP의 자원을 제대로 활용하지 않고 있다면 REST하지 않다고 볼 수 있다.
예비 답안 보기 (👈 Click)
기본적으로 HTTP 프로토콜 환경은 "connectionless, stateless"한 특성을 가지기 때문에 서버는 클라이언트가 누구인지 매번 확인해야 한다.
이 특성을 보완하기 위해서 쿠키와 세션을 사용한다.
- 쿠키
- 클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일
- 세션
- 일정 시간 동안 같은 브라우저로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 유지하는 것
- 세션과 쿠키의 차이점
- 저장 위치
- 쿠키는 클라이언트, 세션은 서버
- 라이프 사이클
- 쿠키는 만료시간까지 유지, 세션은 브라우저 종료 시 삭제
- 속도
- 세션은 정보가 서버에 있기 때문에 처리가 요구되어 쿠키가 더 빠르다.
- 보안
- 쿠키는 클라이언트 로컬에 저장되어 취약하지만, 세션은 서버에서 관리해서 비교적 안전
- 저장 위치
- 세션보다 주로 쿠키를 사용하는 이유
- 세션은 서버의 자원을 사용하기 때문에 사용자가 많은수록 소모되는 자원이 상당하기 때문
- 클라이언트 요청
- Request-Header 필드의 Cookie 에서 세션ID를 보냈는지 확인
- 세션ID가 없을 경우, 서버에서 생성하여 클라이언트에게 전송
- 세션ID가 있는 경우, 쿠키를 사용해 세션ID를 서버에 저장
- 클라이언트 재접속 시, 쿠키를 이용하여 세션ID 값을 서버에 전달
session의 값을 가져오는 key는 “user”입니다. 사용자 A가 접속해도 “user”로 값을 가져오고, 사용자 B가 접속해도 “user”로 가져오는데 어떻게 A와 B가 접속했을때 서로 다른 결과값을 받을수 있나요?
예비 답안 보기 (👈 Click)
클라이언트가 해당 서버에 접속할 때 서버에는 세션 파일을 하나 생성하고 브라우저에게 JSESSIONID라는 쿠키를 전송한다.
다음부터는 브라우저는 다른 페이지로 이동할 때마다 JSESSIONID를 서버로 함께 전송한다.
그럼 서버는 JSESIONID 값을 보고 session을 매칭해서 어떤 사용자인지 체크할 수 있다.
결국에는 다른 session 객체인 것이다.
예비 답안 보기 (👈 Click)
쿠키를 사용할 수 없을 때는 url 뒤쪽에 파라미터 값으로 전달하는 경우가 있다.
예비 답안 보기 (👈 Click)
일반적인 로그인 방식으로는 세션과 쿠기를 통해 구현한다. 세션은 서버의 메모리 내부에 저장되기 때문에 많아지는 만큼 메모리에 부하가 걸리게 되고, 확장 시 세션을 분산시키는 기술을 따로 설계해야 한다.
JWT란 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token이다. JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달한다. 보통 쿠키에 담거나 헤더에 담아서 보내게 되고 서버에서는 따로 저장하지 않고 토큰의 유효성만 검증하면 되기 때문에 세션 관리보다 더 적은 자원을 사용하게 된다.
하지만 탈취에 의해 악의적으로 사용될 가능성이 있기에 보통 유효시간을 짧게 가져가고 Refresh 토큰을 사용하는 방식으로 구현한다.
예비 답안 보기 (👈 Click)
사용자가 애플리케이션에게 자신을 대신하여 특정 자원에 접근할 수 있는 권한을 부여하는 것을 목적으로 하는 인가를 위한 표준 프로토콜
OAuth 2.0 인증 프로토콜이 아니지만, OpenID Connect 프로토콜을 통해서 OAuth 2.0를 기반으로 하여 인증을 제공하는 기능을 추가합니다.
예비 답안 보기 (👈 Click)
- WebSocket
- 개념
- 웹 페이지의 한계에서 벗어나 실시간으로 상호작용하는 웹 서비스를 만드는 표준 기술
- 배경
- HTTP 프로토콜을 클라이언트에서 서버로의 단방향 통신을 위해 만들어진 방법이다.
- 실시간 웹을 구현하기 위해서는 양방향 통신이 가능해야 하는데, WebSocket 이전에는 AJAX를 이용해서 구현했고 각 브라우저마다 구현 방법이 달라 개발이 어려웠다.
- 이를 위해 HTML5 표준의 일부로 WebSocket이 등장했다.
- 특징
- 소켓을 이용하여 자유롭게 데이터를 주고 받는다.
- http 대싱 ws://로 시작하여 streaming과 유사한 방식으로 푸쉬를 지원한다.
- 브라우저와 마찬가지로 서버에서도 WebSocket을 지원해야 한다.
- 아직 확정된 상태가 아니라 브라우저별로 지원하는 WebSocket 버전이 다르다.
- 즉, 시범적 기술로 아직 써볼만한 기술은 아니다.
- 개념
- Socket.io
- 개념
- 다양한 방식의 실시간 웹 기술을 사용할 수 있는 모듈
- WebSocket, FlashSocket, 등 다양한 방법을 하나의 API로 추상화한 것
- Socket.io는 JavaScript를 이용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있도록 한 기술
- 특징
- 현재 바로 사용할 수 있는 기술
- WebSocket을 지원하는 여러 서버 구현체가 있지만 socket.io는 Node.js 밖에 없다.
- 개발자는 socket.io로 개발하고 클라이언트로 푸쉬 메시지를 보내기만 하면, websocket을 지원하지 않는 브라우저의 경우 브라우저 모델과 버전에 따라 다른 방법으로 내부적으로 푸쉬를 보낸다.
- 개념
간단하게 정리하면, 실시간으로 상호작용하는 웹 서비스를 만드는 기술은 여러 개가 있고 표준 기술은 WebSocket이다. 아직 시범적인 기술이고, 이런 것들을 추상화 한 것이 Socket.io이다.
예비 답안 보기 (👈 Click)
두 사람이 서로 통신을 주고 받는데, 중간에 제 3의 인물이 끼여서 데이터를 중계한다면, 이 제3자는 그 내용을 모두 알 수 있고, 데이터를 위/변조할 경우 두 사람에게 서로 잘못된 정보를 전달하게 만들 수도 있다. 중간에서 데이터를 가로채는 것이 중간자 공격이다.
중간자 공격은 4가지가 있다.
- 스니핑
- 시스템 및 네트워크에서 들어오고 나가는 데이터 패킷을 캡쳐한다.
- 패킷 주입
- 공격자가 일반 데이터와 함께 악의적인 데이터를 주입한다.
- 세션 하이재킹
- 세션 가로채기라고도 불리며 두 시스템 간 연결이 활성화된 상태를 가로채는 것
- 보안 소켓 계층 스트리핑
- 공격자는 SSL/TLS 연결을 차단하여 프로토콜 보안성이 있는 HTTPS에서 안전하지 않은 HTTP로 전환한다.
이 공격법을 방어하기 위한 목적으로 만들어진 것이 TLS 통신이다.
TLS 통신은 클라이언트가 연결을 요청하면 서버에서 자신의 공개키가 포함된 인증서를 보내고, 클라이언트는 인증서의 내용을 연결 프로그램(웹 브라우저 등) 또는 운영체제에 내장된 루트 인증서 정보와 비교하여 무결성을 검증한 뒤, 인증서에 있는 공개키로 대칭형 암호화 키를 만들 수 있는 난수 정보를 공개키로 암호화해 서버로 보내며, 클라이언트와 서버가 각각 이 난수에서 암호화 키를 만들어내 암호화 연결이 개시된다.
예비 답안 보기 (👈 Click)
- 정의 : 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(데이터 수정, 삭제, 등록 등) 을 특정 웹사이트에 요청하게 하는 공격이다.
- 방어 방법
- http 요청 헤더에 referer 정보를 통해 host와 referer 일치하는지 확인
- csrf 토큰을 사용하여 사용자 세션에 임의값을 저장하고 요청마다 헤더에 값을 포함하여 전송하도록 하고 서버에서는 세션에 저장된 값과 비교하여 검증