네트워크
#_TCP/IP 4계층 모델과 OSI 7계층 : 인터넷 프로토콜 스위트(internet protocol suite) : 인터넷에서 컴퓨터들이 정보를 주고받는데 쓰이는 프로토콜의 집합으로 TCP/IP 4계층 또는 OSI 7계층 모델로 설명
TCP/IP (Transmission control Protocol/Internet Protocol) 4계층 모델 : 네트워크에서 사용되는 통신 프로토콜의 집합, 프로토콜의 네트워킹 범위에 따라 구성
OSI 7계층 : TCP/IP 세분화
#_TCP/IP 4계층 : 각 계층에 영향x
애플리케이션(application) 계층 : FTP, HTTP, SSH, SMTP, DNS 등 응용프로그램이 사용되는 프로토콜 계층으로 웹 서비스, 이메일 등 서비스를 실질적으로 사람들에게 제공하는 층
| FTP | 장치와 장치 간의 파일을 전송하는데 사용되는 표준 통신 프로토콜 |
| SSH | 보안되지 않은 네트워크에서 네트워크 서비스를 안전하게 운영하기 위한 암호화 네트워크 프로토콜 |
| HTTP | World Wide Web을 위한 데이터 통신의 기초이자 웹 사이트를 이용하는데 쓰는 프로토콜 |
| SMTP | 전자메일 전송을 위한 인터넷 표준 통신 프로토콜 |
| DNS | 도메일 이름과 IP주소를 매핑해주는 서버, 예를 들어 www.naver.com에 DNS쿼리가 오면 [Root DNS] -> [com DNS] -> [naver DNS] -> [www DNS ] 과정을 거쳐 완벽한 주소를 찾아 IP주소를 매핑한다. 이를 통해 IP주소가 바뀌어도 사용자들에게 똑같은 도메인 주소로 서비스할 수 있다. 예를 들어 www.naver.com의 의 IP주소가 222.111.222.111에서 222.111.222.122로 바뀌었음에도 똑같은 www.naver.com 이라는 주소로 서비스가 가능하다 |
전송(transport) 계층 : 송신자와 수신자를 연결하는 통신서비스 제공, 연결지향 데이터 스트림 지원, 신뢰성, 흐름제어 제공, 애플리케이션과 인터넷 계층 사이의 데이터가 잔달될 때의 중계 역할, 연결지향 통신, 신뢰성, 흐름제어, 혼잡제어 기능 포함 ex) TCP, UDP
인터넷(internet) 계층 : 장치로부터 받은 네트워크 패킷을 IP주소로 지정된 목적지로 전송하기위해 사용되는 계층, 패킷을 수신해야할 상대의 주소를 지정하여 데이터 전달하지만 제대로 받았는지 보장하지 않는 비연결형적 특징 ex) IP, ARP, ICMP
링크계층(네트워크 접근 계층) : 전선, 광섬유, 무선 등으로 실질적으로 데이터를 전달하며 장치간에 신호를 주고받는 '규칙'을 정하는 계층, 물리계층(무선 LAN과 유선 LAN을 통해 0과 1로 이루어진 데이터를 보내는 계층) + 데이터 링크계층('이더넷 프레임'을 통해 에러확인, 흐름제어, 접근제어 담당)
#_TCP와 UDP의 차이
TCP : 패킷 사이의 순서 보장, 연결지향 프로토콜(3웨이 핸드쉐이크)을 사용해서 연결하여 신뢰성을 구축, 수신여부를 확인하는 '가상회선 패킷 교환방식' 을 사용
UDP : 순서 보장x, 수신여부확인x, 단순 데이터만 주는 '데이터그램 패킷 교환방식'
* 데이터 전송시 발생오류 (TCP는 모두 방지 및 제거 가능, UDP는 내부 손상만 가능)
ⓐ 패킷의 잘못된 순서(TCP는 시퀀스)
ⓑ 패킷 손실(TCP는 재전송가능)
ⓒ 패킷 내부의 손상된 데이터 (UCP, TCP 모두 체크섬 기반 체크) *체크섬 : 헤더, 패킷내용, IP 기반으로 체크섬을 만들어 패킷내부의데이터 손상 파악
#_3웨이 핸드쉐이크 : 연결성립과정, 신뢰성 확보 (TCP에는 있고 UDP는 없는 과정)
- SYN 단계 : 클라이언트는 클라이언트의 ISN(새로운 TCP연결의 첫번째 패킷에 할당된 임의의 시퀀스 번호)을 담아 SYN을 보냄
- SYN + ACK 단계 : 서버는 클라이언트의 SYN을 수신, 서버의 ISN을 전송, 승인번호로 클라이언트의 ISN+1 전송
- ACK 단계 : 클라이언트는 서버의 ISN+1의 값인 승인번호를 담아 ACK를 서버에 전송
* SYN : SYNchronization, 연결 요청 플래그
* ACK : ACKnowlegement, 응답 플래그
* ISN : Initial, Sequence, Numbers의 약어, 초기 네트워크 연결시 할당된 32비트 고유 시퀀스 번호
#_4웨이 핸드쉐이크 : 연결해제과정
- 클라이언트가 연결해제시 FIN으로 설정된 세그먼트 전송, 클라이언트는 FIN_WAIT_1상태가 되고 서버응답 대기
- 서버는 클라이언트에 ACK라는 승인세그먼트 전송, CLOSE_WAIT상태가 됨, 클라이언트가 세그먼트를 받으면 FIN_WAIN_2 상태가 됨
- 서버는 ACK를 보내고 일정시간 후 클라이언트에 FIN이라는 세그먼트 전송
- 클라이언트는 TIME_WAIT상태가 되고 다시 서버로 ACK를 보내서 서버는 CLOSED상태가 됨, 이후 클라이언트는 대기 후 연결이 닫히고 클라이언트와 서버의 모든 지원 연결이 해제됨
* TIME_WAIT : 소켓이 즉시 소멸되지 않고 일정시간 유지되는 상태, 지연 패킷으로 인한 데이터 무결성 문제 대비, CentOS6, 우분투에는 60초, 윈도우는 4분 설정으로 OS마다 차이가 있음
* 데이터 무결성(data integrity) : 데이터의 정확성과 일관성을 유지하고 보증하는 것
#_홉바이홉(hop by hop) 통신 : IP주소를 통해 통신하는 과정, 각각의 라우터에 있는 라우팅 테이블의 IP를 기반으로 패킷을 전달해나가서 최종목적지에 다다르는 것으로 통신망에서 각 패킷이 여러개의 라우터를 건너가는 모습을 비유적으로 표현한 것
#_라우팅 : IP주소를 찾아가는 과정
#_라우팅테이블(routing table) : 송신지에서 수신지까지 도달하기 위해 사용되며 라우터에 들어가있는 목적지 정보들과 목적지로 가기위한 방법(게이트웨이, 목적지 도달을 위한 다음 라우터의 정보)이 들어있는 리스트
* 게이트웨이(gateway) : 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 가능케하는 관문 역할의 컴퓨터 도는 소프트웨어, 사용자는 인터넷 접속을 위해 수많은 게이트웨이를 거쳐야하며 게이트웨이는 서로 다른 네트워크상의 통신 프로토콜을 변환하는 역할
#_IP와 라우팅 : 윈도우 명령 프롬프트 netstat-r명령어를 실행하여 라우팅 테이블(IPv4, IPv6 경로테이블), 게이트웨이, 인터페이스 등 확인 가능
#_ARP(Address Resolution Protocol) : IP주소로부터 MAC주소를 구하는 IP(가상, 논리적주소)와 MAC주소(실제, 물리적주소)의 다리 역할을 하는 프로토콜
↕
#_RARP : 실제주소인 MAC를 가상주소인 IP주소로 변환
* 브로드캐스트 : 송신 호스트가 전송한 데이터가 네트워크에 연결된 모든 호스트에 전송되는 방식
* 유니캐스트 : 고유주소로 식별된 하나의 네트워크 목적지에 1:1데이터를 전송하는 방식 ex) 1:1 채팅
#_캡슐화과정과 비캡슐화과정
PDU (Protocol Data Unit, 프로토콜 데이터 단위)
애플리케이션 계층 : 메시지
전송 계층 : 세그먼트(TCP), 데이터그램(UDP) / +TCP(L4)
인터넷 계층 : 패킷 / IP(L3)
링크 계층 : 프레임(데이터 링크 계층), 비트(물리 계층)
#_url 입력시 화면이 나타나기까지
: 대기열-> 캐싱-> DNS-> 라우팅-> ARP-> 초기연결->컨텐츠 다운-> 브라우저렌더링의 과정(캡슐화, 비캡슐화)을 거쳐 화면이 나타남
1. 대기열 : 브라우저는 주소창입력에 대한 요청을 대기열에 넣음
2. 캐싱 : 요청된 결과값 저장, 재요청시 다시 제공하는 기술, 공유프록시캐시와 브라우저 캐시가 있음
* 브라우저 캐시 : 쿠키, 로컬스토리지 등을 포함한 캐시, 브라우저 자체가 사용자가 HTTP를 통해 다운로드하는 모든 문서를 보유하는 것, 사이트 재방문시 컨텐츠가 빠르게 나타남
* 공유 프록시 캐시 : 요청한 서버에서 프록시서버가 캐싱하는 것, ex) Node.js로 서버를 구축할 때 앞단의 프록시서버로 nginx서버를 두고 캐싱 서버로 사용
3. DNS : 브라우저가 요청의 IP주소를 확인하는 단계, 도메일이름과 IP주소를 매핑해주는 서버, DNS서버 요청 전 컴퓨터 메모리의 호스트파일 등 캐시를 확인 후 캐시미스가 발생하면 요청함
4. IP 라우팅 -> ARP : 서버를 찾음
5. 초기연결 : 브라우저가 TCP3웨이, 핸드셰이 및 SSL연결 등을 통해 연결 설정, 해당 요청 서버로부터 응답받음
6. 콘텐츠 다운로드
7. 브라우저렌더링
#_HTTP/1.0 (Hypertext Transfer Protocol) : 기본적으로 한 연결당 하나의 요청 처리 -> RTT 증가
단점) RTT증가 : 서버로부터 파일을 가져올 때마다 TCP의 3웨이 핸드셰이크를 열어야하므로 RTT가 증가함
* RTT : 패킷이 목적지에 도달 후 다시 출발지로 돌아오기까지 걸리는 시간, 패킷 왕복시간
↓
RTT증가를 해결하기 위한 방법
① 이미지 스플리팅 : 많은 이미지를 다운로드받게 되면 과부하가 걸리기 때문에 합쳐진 하나의 이미지를 다운로드받고 이를 기반으로 background position을 이용하여 이미지를 표기하는 방법
② 코드압축(minify) : 개행문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법, 코드압축 -> 코드용량이 줄어듬
③ 이미지 Base64인코딩 : 이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법, 서버와 연결을 열고 이미지에 대해 서버에 HTTP요청이 불필요하다는 장점과 크기가 약 37%정도 커진다는 단점이 있음
* 인코딩 : 정보의 형태나 형식을 표준화, 보안, 처리속도 향상, 저장 공간 절약 등을 위해 다른 형식으로 변환하는 처리방식
#_HTTP/1.1 : 매번 TCP 연결이 아닌 한 번 TCP초기화 후 keep-alive옵션으로 여러개의 파일을 송수신 (1.0은 옵션은 있지만 표준화x, 1.1부터 표준화ㆍ기본옵션 설정)
단점) HOL Blocking (Head Of Line Blocking) : 네트워크에서 같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상 ex) img.jpg, style.css, data.xml을 다운로드 받을 때 순차적으로 진행되므로 img.jpg가 지연되면 style.css와 data.xml도 다운로드가 지연됨
#_HTTP/2 : SPDY 프로토콜에서 파생된 HTTP/1.x보다 지연시간을 줄이고 응답시간을 빠르게하며 멀티플렉싱, 헤더압축, 서버푸시, 요청의 우선순위 처리를 지원하는 프로토콜
- 멀티플렉싱 : 여러개의 스트림을 사용하여 송수신, 특정 스트림 패킷이 손실되어도 해당 스트림 외는 정상 작동
* 스트림(stream) : 시간이 지남에 따라 사용할 수 있게되는 일련의 데이터 요소를 가리키는 데이터 흐름
- 헤더압축 : HTTP/1.x의 단점인 크기가 큰 헤더를 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축형식으로 해결
* 허프만 코딩(huffman coding) : 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하고 빈도가 낮은 정보는 많은 비트수로 표현하여 전체 데이터 표현에 필요한 비트양을 줄이는 원리의 알고리즘
- 서버푸시 : HTTP/1.1은 클라이언트가 서버요청시 파일을 다운로드 받을 수 있으나 HTTP/2는 클라이언트 요청없이 서버가 바로 리소스 푸시가능 ex) html에는 css, js가 포함되어 있는데 html을 읽으면서 내부의 css파일을 서버에 푸시하여 클라이언트에 우선 제공 가능
#_HTTP/3 : HTTP/2는 TCP기반, HTTP/3는 QUIC계층의 UDP기반으로 HTTP/2의 멀티플렉싱 + "초기연결설정시 지연시간 감소"
QUIC는 TCP를 사용하지 않으므로 통신을 시작할 때 3웨이 핸드셰이크 과정이 없음, 첫 연결 설정에 1-RTT만 소요됨, 클라이언트가 서버에 신호를 한번보내고 서버가 응답하면 곧바로 본 통신 시작 가능
* QUIC는 순방향 오류 메커니즘(FEC, Forwrad Error Correction) 적용, 전송한 패킷이 손실되었을 경우 수신측에서 에러를 검출ㆍ수정하는 방식으로 열악한 네트워크 환경에서도 낮은 패킷 손실률을 보임
#_HTTPS : HTTP와 달리 애플리케이션 계층과 전송 계층 사이에 신뢰계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP로 이를 통해 '통신 암호화'함
#_SSL (Secure Socket Layer) / TLS (TransportLayer Security Protocol) : SSL 1.0, SSL 2.0, SSL 3.0, TLS1.0, TLS1.3으로 버전이 올라가며 명칭이 변경됨, 전송 계층에서 보안을 제공하는 프로토콜로 클라이언트와 서버가 통신할 때 제3자가 메시지를 도청하거나 변조하지 못하도록 함, SSL/TLS는 보안세션을 기반으로 데이터를 암호화하여 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘을 사용하여 공격자가 서버인척 사용자의 정보를 가로채는 네트워크상의 인터셉트를 방지함
1. 인증메커니즘
클라이언트 : *사이퍼 슈트(요청 : 인증서 만들어주세요)
-> 서버(암호화 알고리즘 리스트 제공여부 확인) : 인증서(*인증메커니즘/ 응답 : 우리의 인증서는 aaa입니다)
-> 클라이언트
2. *키교환 암호화 알고리즘
3. *해싱 알고리즘
4. 보안세션 생성 : 보안이 시작되고 끝나는 동안 유지되는 세션, SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성, 상태정보를 공유함
* 세션 : 운영체제가 어떠한 사용자로부터 자신의 자산 이용을 허락하는 일정한 기간(보안유지기간), 사용자는 일정시간동안 응용프로그램, 자원 등을 사용할 수 있음
5. 데이터 송수신
==> 클라이언트가 서버와 키를 공유하고 이를 기반으로 인증, 인증 확인 등의 작업이 일어나는 단 한번의 1-RTT가 생긴 후 데이터 송수신
*사이퍼 슈트 : 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약
ex) TLS_AES_128_GCM_SHA256 은 TSL 프로토콜, AES128_GCM 사이퍼모드, SHA256 해싱 알고리즘의 조합
*인증 메커니즘 : CA(Certificate Authorities)에서 발급한 인증서 기반으로 CA에서 발급한 인증서는 '공개키'를 클라이언트에 제공하고 사용자가 접속한 '서버가 신뢰'할 수 있는 서버임을 보장함, 인증서는 서비스정보, 공개키, 지문, 디지털 서명 등으로 이루어짐
* CA : 신뢰성이 엄격하게 공인된 기업들(Comodo, GoDaddy, GlobalSign, 아마존 등)만 참여가능
*키교환 알고리즘 : 클라이언트와 서버 모두 개인키와 공개키를 생성하고 서로에게 공개키를 보내고 공개키와 개인키를 결합하여 PSK(사전 합의된 비밀키)가 생성된다면 공격자가 공격하지 못함
g, x, p를 안다면 y는 구하기 쉽지만 g, y, p만 안다면 x는 구하기 어렵다는 원리에 기반한 알고리즘
*해싱 알고리즘 : 데이터를 추정하기 힘든 더 작고 섞인 조각으로 만드는 알고리즘, SHA-256, SHA-384 알고리즘 사용
*SHA-256 : 해시 함수의 결괏값이 256비트인 알고리즘, 블록체인 시스템에서 사용, 해싱해야할 메시지에 1을 추가하는 등 전처리를 한 메시지를 기반으로 해시를 반환
*해시 : 다양한 길이를 가진 데이터를 고정된 길이를 가진 데이터로 매핑한 값
*해싱 : 임의의 데이터를 해시로 바꿔주는 일로 해시함수가 담당
*해시함수 : 임의의 데이터를 입력으로 받아 일정한 길이의 데이터로 바꿔주는 함수
* SHA-256 사이트링크 https://emn178.github.io/online-tools/sha256.html
- TLS1.3은 사용자가 이전에 방문한 사이트로 다시 방문한다면 SSL/TLS에서 보안세션을 만들때 걸리는 통신 불필요(0-RTT)
- HTTPS 구축방법
① 직접 CA에서 구매한 인증키를 기반으로 HTTPS서비스를 구축
*CA인증서 발급과정 : 자신의 사이트 정보, 공개키를 CA에 제출하여 하는 CA의 비밀키(공개키를 해시한 값인 지문(finger print)를 사용) 등을 기반으로 발급
② 서버 앞단의 HTTPS를 제공하는 로드밸런서를 둠
③ 서버앞단에 HTTPS를 제공하는 CDN을 둠
#_로그인 : HTTP는 stateless하여 연결을 끊는 순간 사용자와 서버의 통신이 끝나며 상태정보는 유지하지 않기때문에 이 '상태'를 유지하는 방법으로 ⓐ 쿠키와 세션 ⓑ 토큰기반 방식이 있음
#_쿠키와 세션
- 세션 : 서버와 클라이언트의 연결이 활성화된 상태
- 세션ID : 웹 서버메모리에 저장되는 클라이언트에 대한 유니크한 ID (서버, 데이터베이스에 저장)
- 쿠키 : 키와 값으로 구성된 작은 데이터 조각, 쿠키에 담긴 데이터는 브라우저에서 관리됨(만료날짜는 서버에서 설정), 이름ㆍ값ㆍ만료날짜 등으로 구성
1. 로그인 -> 쿠키, 세션ID 생성하여 후에 다시 요청시 HTTP헤더에 쿠키를 포함하여 요청
2. 해당 쿠키에 맞는 세션 ID로 전에 로그인했던 아이디인지 확인
3. 로그인 유지
* XSS(Cross Site Scripting) : 쿠키는 클라이언트에서 JS로 조회가 가능하여 공격자들이 JS로 쿠키를 가로채는 시도를 함
-> 해결방법 : HTTP Only Cookie 또는 secure cookie를 사용
Set-Cookie : 쿠키명 = 쿠키값; path=/; secure
Set-Cookie : 쿠키명 = 쿠키값; path=/; HttpOnly
보통은 HTTP관련 라이브러리에 적힌대로 axios.defaults.withCredentials = true;
단점
1. 로그인 중인 유저의수가 증가하면 서버의 메모리 과부하 등 악영향(로그인시마다 세션 ID저장으로)
-> (해결) 토큰기반인증 방식 : JWT토큰(대표적), 인증은 토큰기반인증서버를 통하고, 서버는 stateless하도록
*토큰기반인증 : 요청 -> 토큰생성 -> 사용자가 토큰을 헤더(authorization 키에 넣어 요청, 해당 토큰 기반)
#_JWT (JSON Web Token, RFC 7519) : 헤더, 페이로드, 서명으로 이루어짐, JSON객체로 인코딩, 메시지 인증, 암호화에 사용
- Header : 어떤 방법의 서명 알고리즘을 사용할 것인가에 대한 정보
- Payload : 데이터, 토큰 발급자, 토큰 유효기간(인증이 필요한 최소한의 정보만)
- Signature : 헤더에 정의된 알고리즘으로 인코딩된 헤더와 페이로드를 합친값, 비밀키를 기반으로 생성된 서명값
장점)
① 사용자가 인증되면 사용자는 모든 시스템에서 사용할 수 있는 보안 토큰을 받음, 단일 엔드포인트를 생성해서 다른 모든 서버간의 API 상호작용을 인증할 수 있음
② 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함해서 별도의 인증저장소 불필요(세션의 경우는 계속해서 저장해야함)하므로 확장성, 디버깅, 작은 사이즈, 독립적임
단점)
더 많은 필드가 추가되면 토큰이 비대해져 트래픽에 영향, 탈취하여 디코딩하면 데이터를 볼 수 있음
#_브라우저 렌더링과정
1. DOM 트리 구축 : html페이지의 각 요소를 하나하나 노드(Node)로 설정되어 트리형태로 저장
2. 렌더트리와 렌더레이어 생성 : 각 노드는 CSS파서에 의해 정해진 스타일 규칙이 적용됨, 이런 규칙에 따라 CSSOM이라는 트리가 만들어지고 미리 만들어놓은 DOM트리내의 노드와 함께 렌더객체(Render Object)가 생성, display:none의 노드는 지워지고 상속적인 스타일은 부모노드에만 위치하도록 설계하는 등의 최적화를 거쳐 렌더레이어가 완성됨
DOM트리:렌더트리 = 1:1 -> 렌더레이어 (GPU처리부분(CSS3D, video&canvas, filter, animation, transform:translateZ(0) 등)은 강제적으로 각각 그래픽 레이어로 분리됨
3. 렌더레이어를 대상으로 layout 설정 : 부모기준 좌표, global layout 은 브라우저 사이즈가 증가하거나 폰트사이즈가 커지면 변경됨
4. 렌더레이어를 대상으로 칠하기(paint) : 픽셀마다 점 찍듯 칠함, 레스터화
5. 레이어 합치기(composite layer) 및 표기 : 각 레이어로부터 비트맵 생성, GPU에 텍스처로 업로드, 텍스처들은 합쳐져 하나의 이미지로 렌더링되어 화면에 출력
#_로컬스토리지와 세션스토리지 : 웹스토리지, HTML5와 함께 도입, '브라우저 스토리지'에 저장되는 조각으로 크롬을 사용한다면 크롬에만 저장되고 그 정보를 파이어폭스 등 다른 브라우저에서 볼 수 없음, 오리진(protocol+host)에 종속됨
#_로컬스토리지 : 웹 브라우저에서 키/값 쌍의 형태로 클라이언트 브라우저에 데이터를 저장하는 방법, 데이터는 사용자가 브라우저에서 수동으로 삭제하지 않는 한 만료날짜가 없음, 저장용량은 최대 10mb(일반적으로 5mb), 사용자가 창이나 탭을 닫아도 만료되지 않음, 브라우저의 메모리가 지워질 때까지 브라우저에 남음, 데이터는 자동으로 서버에 전송되지않음
설정 : localStorage.setItem(key, value);
탐색 : localStorage.getItem(key);
제거 : localStorage.removeItem(key);
전체제거 : localStorage.clear();
#_세션스토리지 : 로컬스토리지와 매우 유사하며 탭을 닫을 때 삭제됨, 최대 5mb
#_쿠키 : 클라이언트에 데이터를 저장하는 방법 중 하나, 요청시마다 서버에 자동으로 전송됨, 클라이언트와 서버 둘다 조작 가능, 보통 서버에서 만료기한 등을 설정 및 컨트롤 함, Set-Cookie헤더에 설정된 작은 데이터 조각 4kb까지 가능
- 세션쿠키 : expires, max-age와 같은 속성 지정x, 브라우저가 닫힐 때 제거됨
- 영구쿠키 : expires, max-age와 같은 속성 지정함, 브라우저가 닫힐 때 제거되지않지만 일정기간 후 제거됨
- secure : https로만 가능하나 일부 브라우저는 보안강화를 위해 해당사양 적용x
ⓐ httponly : 공격자가 JS로 빼낼 수 없음(document.cookie로 접근 불가)
Set-Cookie : <cookie-name>=<cookie-value>; Httponly
ⓑ 요청이 동일한 도메인에서 시작된 경우에만 쿠키가 어플리케이션으로 전송되도록 허용
Set-Cookie : <cookie-name>=<cookie-value>; SameSite=Strict
실습 : https://github.com/wnghdcjfe/csnote/blob/main/ch2/cookie/server.js
#_세션ID 설정시 : 보통 쿠키에서 세션 ID를 담는데 세션 ID기반으로 클라이언트의 인증정보를 알수 없게 해야함, 세션 ID를 공격자가 추측하기 어렵게 길고 랜덤하게 생성하는 알고리즘과 사용자수에 대비, 충분히 큰 수로 하고 http only 옵션, 세션 타임아웃
#_쿠키의 시큐어코딩 : 쿠키는 간접수집에 해당하며 해당 지침을 준수하여 서비스를 추국해야함
#_로컬스토리지, 세션스토리지, 쿠키가 필요한 이유 : 서버에 대한 요청을 줄이고 네트워크 연결없이 웹사이트를 더 빨리 다운로드하기 위해, 사이트 기본설정 커스터마이징(색상, 글꼴 크기 등), 로그인상태 저장 등에 사용
#_로컬스토리지, 세션스토리지, 쿠키의 차이
#_HTTP의 상태코드와 메서드(GET, POST, PUT, PATCH, DELETE)
| 1xx (정보) | 요청을 받았으며 프로세스를 계속함 | |
| 2xx (성공) | 요청을 성공적으로 받았으며 인식했고 수용함 | |
| 200 OK | 성공적으로 요청됨 | |
| 201 Created | 성공적으로 요청되었으며 그 결과로 새로은 리소스가 생성됨 | |
| 3xx (리다이렉션) | 요청 완료를 위해 추가 작업조치 필요 | |
| 301 Moved Perma nently | 요청한 리소스의 URI가 변경됨, 변경된 새로운 URI에서 응답 필요 | |
| 4xx (클라이언트 오류) | 요청의 문법이 잘못되었거나 요청처리 불가 | |
| 400 Bad Request | 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음 | |
| 401 Unauthorized | 클라이언트의 인증이 되지않음 | |
| 5xx (서버 오류) | 서버가 명백히 유효한 요청에 대해 충족을 실패함 | |
| 500 Internal Server Error | 서버에 오류가 있음 | |
| POST | 자원 생성 |
| 보통 하위자원을 생성하는데 예를 들어 book테이블내의 데이터를 생성, 성공적으로 생성시 HTTP상태 201 반환 | |
| GET | 읽기 |
| 성공시 200, 오류의 경우 가장 자주 404(NOT FOUND) 또는 400(BAD REQUEST)를 반환함, 데이터 수정 삭제시 사용하면 안됨 |
|
| PUT | 업데이트 (전체자원) |
| 요청을 보낼때 전체를 보냄 ex. {"a":1, "b":2} -> {"a":1, "b":3} | |
| PATCH | 업데이트(일부자원) |
| 요청을 보낼때 수정하는 일부분을 보내야함 ex. {"a":1, "b":2} -> {"b":3} | |
| DELETE | 삭제 |
#_API : Application Programming Interface, 소프트웨어와 소프트웨어사이 데이터 전송을 가능케파는 프로그램
#_REST API : 웹의 장점을 잘 살린 아키텍처, Uniform-Interface를 가짐
* Uniform-Interface : 자원들이 각각의 독립적인 인터페이스를 가짐, 웹페이지를 변경해도 웹브라우저를 업데이트하는 일은 발생x, HTTP명세나 HTML명세가 변경되어도 웹페이지는 잘 작동해야함
특징
① Self-descriptive messages : HTTP Header에 타입을 명시하고 각 메시지(자원)들은 MIME types에 맞춰 표현되어야 함
ex. .json을 반환한다면 application/json으로 명시해야함
*MIME types는 문서, 파일 등의 특성과 형식을 나타내는 표준으로 IETF의 RFC6838에 정의, 표준화 되어있음('font/ttf', text/plain', 'text/csv')
② HATEOAS 구조 : 하이퍼링크에 따라 다른 페이지를 보여줘야하며 데이터마다 어떤 URL에서 원했는지 명시해야함
③ Stateless : HTTP자체가 Stateless이므로 HTTP를 이용하는 것만으로 만족됨, 즉 REST API를 제공해주는 서버는 세션(session)을 해당 서버쪽에 유지하지 않음
④ Cacheable : HTTP는 원래 캐싱이 됨, 새로고침시 304가 뜨고 기존의 JS와 CSS, 이미지 등을 불러오는데 이러한 캐싱은 네트워크 요청을 줄여주며 UX향상에 도움, 네트워크 요청시 해당되는 자원들을 복사해서 메모리에 저장하고 같은 요청시 네트워크 요청을 하지않고 브라우저메모리에 있던 자원을 반환함,
HTTP메서드 중 GET에 한정되며 'Cache=Control:max-age=100'(100초) 와 같이 한정된 시간 설정 가능, 캐싱된 데이터가 유효한지 판단하기 위해 'Last-modified', 'Etag'사용 (Etag: 전달되는 값에 태그를 붙여 캐싱되는 자원인지 확인
⑤ Client-Server 구조 : 클라이언트와 서버가 서로 독립적인 구조, HTTP를 통해 가능한 구조로 서버에서 HTTP표준을 준수하면 웹에서는 그에 따른 화면이 보여짐, 서버의 역할은 API를 제공하고 해당하는 비지니스 로직처리, 클라이언트는 HTTP로 받는 로직처리
⑥ Layered System : 계층구조로 아키텍처를 만들 수 있음
#_URI 규칙
① 동작은 HTTP메서드로, 수정(put), 삭제(delete), 추가(post), 조회(get)
② 확장자 표기x
③ 명사로만 표기 ex.유저/유저아이디/inclusion/책/책아이디
④ 계층적 내용 ex.집/아파트/전세
⑤ 소문자, 하이픈 사용
⑥ HTTP응답 상태코드 활용
'CS 지식 > [inflearn] CS 전공지식 (완)' 카테고리의 다른 글
| 개발자면접을 위한 CS전공지식 | CS면접 - 자료구조 (0) | 2022.07.29 |
|---|---|
| 개발자면접을 위한 CS전공지식 | CS면접 - 데이터베이스 (0) | 2022.07.28 |
| 개발자면접을 위한 CS전공지식 | CS면접 - 운영체제 (0) | 2022.07.19 |
| 개발자면접을 위한 CS전공지식 | CS면접 - 디자인패턴 (0) | 2022.07.12 |