[컴퓨터 네트워크] 애플리케이션 계층 -2- (보안, JWT, 프록시, REST..)

쿠키와 세션의 차이

사용 이유

HTTP 프로토콜의 특징이자 약점을 보완하기 위해 사용한다.

HTTP는 Connectionless 즉, 비연결형 프로토콜이다. 클라이언트가 서버에 요청을 했을 때, 그 요청에 맞는 응답을 보낸 후 연결을 끊는 처리 방식이다. HTTP가 TCP(TCP:연결 지향) 위에서 구현되었기 때문에 연결지향이라는 논란이 있지만, 서버 측에서 비연결 지향적인 특성으로 커넥션 관리에 대한 비용을 줄이는 것이 명확한 장점으로 보기 때문에 비연결 지향으로 생각하자.
HTTP는 Stateless 프로토콜 커넥션을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다. 하지만, 실제로는 데이터 유지가 필요한 경우가 있다. → 따라서, Stateful 경우를 대처하기 위해 쿠키와 세션을 사용한다.

서버와 클라이언트가 통신을 할 때 통신이 연속적으로 이어지지 않고 한 번 통신이 되면 끊어진다.

쿠키(Cookie)

쿠키는 사용자가 웹사이트를 방문할 때, 웹 사이트가 사용자의 브라우저에 저장하는 작은 텍스트 파일.

쿠키 특징
- 하나의 도메인 당 20개의 쿠키를 가질 수 있다.
- 하나의 쿠키는 4KB까지 저장 가능하다
- 클라이언트에 총 300개의 쿠키를 저장할 수 있다.
- 이름, 값, 만료일, 경로 정보로 구성되어 있다.
동작 순서
- 클라이언트가 페이지를 요청한다.(사용자가 웹사이트에 접근)
- 웹 서버는 쿠키를 생성한다.
- 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려준다.
- 받은 쿠키는 클라이언트 PC에 저장했다가 다시 서버 요청할 때 요청과 함께 쿠키를 전송한다.
사용 예시
- 방문 사이트에서 로그인 시, “아이디와 비밀번호를 저장하시겠습니까?”
- 팝업창을 통해 “오늘 이 창 다시 보지 않기”체크

세션(Session)

일정 시간 동안 같은 사용자(브라우저)로 부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술이다.

방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.

특징
- 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
- 웹 서버에 저장되는 쿠키
- 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.
- 저장 데이터에 제한이 없다.(서버 용량 한에서)
- 각 클라이언트에 고유 Session ID를 부여한다.(세션ID로 클라이언트를 구분)
동작 순서
- 클라이언트가 페이지를 서버에 요청한다.
- 서버는 접근한 클라이언트의 헤더 필드인 Cookie를 확인하여, 클라이언트가 Session-id를 보냈는지 확인한다.
- session-id가 존재하지 않는다면 서버는 session-id를 생성해 클라이언트에게 넘겨준다.
- 클라이언트는 서버로부터 받은 session-id를 쿠키에 저장한다
- 클라이언트는 서버에 요청 시 이 쿠키의 session-id 값을 서버에 전달한다.
- 서버는 전달받은 session-id로 session에 있는 클라이언트 정보를 가지고 요청을 처리 후 응답한다.
예시
- 화면을 이동해도 로그인이 풀리지 않고 유지

쿠키와 세션의 차이

세션도 결국 쿠키를 사용하는 방법이기 때문에 쿠키와 세션은 비슷하다.

둘의 가장 큰 차이점은 사용자의 정보가 저장되는 위치다. 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용한다.

보안 면에서 세션이 더 우수하며 쿠키는 로컬에서 변환될 가능성이 있어 보안에 취약하지만 세션은 쿠키를 이용해서 session-id만 저장하고 그것으로 구분하여 서버에서 처리하기 때문에 비교적 보안성이 높다.

라이프사이클은 쿠키의 유지기간 설정 유무에 따라 유지여부가 달라진다. 쿠키 유지시간 없이 기본적으로 브라우저를 닫으면 쿠키는 사라진다.

Q. 세션을 사용하면 좋아보이는데 쿠키를 왜 사용할까?

세션이 쿠키에 비해 보안성이 높지만 서버 자원을 소모하게 되고 세션을 서버에서 인증하고 처리해야하기 때문에 속도 면에서 쿠키가 훨씬 빠르다. 웹 사이트의 속도를 고려하여 자원 낭비를 방지하기 위해 기능을 선택할 수 있어야한다.

JWT 토큰

JWT는 일반적으로 클라이언트-서버, 서비스-서비스 간 통신 시 권한 인가(Authorization)를 위해 사용하는 토큰이다.
문자열로 구성되어 있기 때문에 URL, HTTP 헤더 등 어디든 위치할 수 있다.

구조

HEADER.PAYLOAD.SIGNATURE

JWT는 헤더, 페이로드, 서명으로 이루어져 있고 점(.)으로 구분된다.

헤더(Header)

{
		"alg": "ES256",
		"kid": "Key ID"
}

헤더는 JWT를 어떻게 검증할지에 대한 내용을 담고 있다.
alg는 서명 시 사용하는 알고리즘, kid는 서명 시 사용하는 키를 식별하는 값이다.
인코딩 시 아래와 같이 헤더를 생성할 수 있다.

Base64URLSafe(UTF-8('{"alg": "ES256","kid": "Key ID"}')) -> eyJhbGciOiJFUzI1NiIsImtpZCI6IktleSBJRCJ9

페이로드(Payload)

{
		"iss": "jinho.shin",
		"iat": "151413132"
}

페이로드는 JWT의 내용이다. 페이로드에 있는 속성들을 클레임 셋이라 부른다.
클레임 셋은 jwt에 대한 내용이나 클라이언트와 서버 간 주고받기 위한 값들로 구성된다.
위 JSON 객체로 아래와 같이 페이로드로 인코딩할 수 있다.

Base64URLSafe('{"iss": "jinho.shin","iat": "1586364327"}') -> eyJpYXQiOjE1ODYzNjQzMjcsImlzcyI6ImppbmhvLnNoaW4ifQ

서명(Signature)

점(.)을 구분자로 해서 헤더와 페이로드를 합친 문자열을 서명한 값이다.
서명은 헤더의 alg에 정의된 알고리즘과 비밀키를 사용해 생성하고 인코딩한다.

Base64URLSafe(Sign('ES256', '${PRIVATE_KEY}',
'eyJhbGciOiJFUzI1NiIsImtpZCI6IktleSBJRCJ9.eyJpYXQiOjE1ODYzNjQzMjcsImlzcyI6ImppbmhvLnNoaW4ifQ'))) ->
MEQCIBSOVBBsCeZ_8vHulOvspJVFU3GADhyCHyzMiBFVyS3qAiB7Tm_MEXi2kLusOBpanIrcs2NVq24uuVDgH71M_fIQGg

JWT 생성과 검증

서버는 사용자에 대해 인증(Authentication)을 수행한다.
인증이 되면, 비밀키와 공개키를 생성하고 헤더와 페이로드를 인코딩한 다음 둘을 합친 문자열을 비밀키로 서명해서 JWT를 만들어 클라이언트에게 전달한다.
서버는 JWT의 서명을 공개키로 검증한다.

JWT토큰과 세션의 차이

서버에 인증 정보를 저장하는 세션과 달리 JWT는 서버에 인증 정보를 저장하지 않는다. 따라서 JWT는 클라이언트의 요청마다 인증을 위해 DB를 탐색하는 과정이 불필요하고, 저장 공간도 필요하지 않다.

리프레시 토큰이 사용되는 이유

Access Token만 쓸 경우
- 토큰 만료 전까지 아무나 마음대로 내 서비스에 들어올 수 있다
- 시간이 짧으면 사용자가 계속 로그인 해야 함.
Refresh Token을 쓸 경우
- Access Token을 짧게 쓰고 Refresh Token으로 새 엑세스 토큰을 쉽게 발급받게 해서 보안과 편의를 챙길 수 있음. 안전장치가 하나 더 생긴 것
- 토큰 재사용 방지 가능. 이미 사용된 리프레쉬 토큰으로 요청이 오면 해킹 의심하여 리프레시 토큰 강제 만료와 사용자 강제 로그아웃이 가능하게 할 수 있음

서버에 Refresh Token을 저장하는 이유는 검증 때문이 아니라 추가 조치를 하기 위해 저장하는 것이다. 즉, 리프레쉬 토큰이 있으면 탈취 감지와 회수가 가능하다.

리프레시 토큰과 세션의 차이점?

리프레시 토큰의 정보가 서버에 저장되면 마찬가지로 서버에 세션 정보를 저장하는 세션 방식과 어떤 차이가 있을까?

비슷하지만 차이가 존재한다. 세션은 매 요청마다 세션 아이디로 DB속 유저의 정보에 접근해야 하지만 리프레시 토큰은 재발급 시점에만 유저의 정보를 접근하면 되기 때문에 DB의존 시점을 줄일 수 있다.

SOP란

Same-Origin Policy 은 자바스크립트 엔진 표준 스펙에 존재하는 보안 규칙
- Origin(Protocol + Host + Port)가 모두 같은 겨우에만, 서로의 중요한 데이터에 접근할 수 있다
브라우저에서 다른 Origin에 대해 JS가 할 수 있는 행동을 강하게 제한한다는 뜻
왜 SOP가 필요할까?
- XSS 등으로 탈취된 스크립트가 다른 사이트의 쿠키, 토큰 등을 훔쳐가는 것을 막기 위해.
- JS가 브라우저 안에서 네이버, 구글 같은 탭의 쿠키 / localStorage / 응답 데이터에 마음대로 접근 가능하다면 로그인 세션, JWT, 민감 데이터를 다 탈취당할 수 있다.

CORS란

Cross Origin Resource Sharing
CORS는 현재 접속한 도메인 말고 다른 도메인에 접근할 수 있도록 처리 해주는 웹 브라우저 표준 기술이다.(원래는 SOP 때문에 안된다.)
만약 프론트엔드와 백엔드가 도메인이 다르다면 SOP 정책에 의해 프론트엔드는 백엔드의 API를 호출할 수 없을 것이다. 이 경우 CORS를 사용해서 해결할 수 있다.
- 백엔드에서 응답 HTTP 헤더에 Access-Controll-Allow-Origin을 추가한다.)

Rest API(Representational State Transfer)

REST는 2000년도 Roy Fielding의 박사 논문에서 최초로 소개된 소프트웨어 아키텍처다.
자원의 표현을 가지고 상태를 전달한다는 뜻이다.
자원의 표현: HTTP URI
상태: HTTP Status code
전달: HTTP Method
REST는 자원을 HTTP URI로 표현하고 HTTP METHOD를 통해 자원의 상태를 주고 받는 아키텍처
RESTful: REST 아키텍처 스타일의 제약조건을 모두 만족하는 시스템을 뜻한다.
REST API: REST 스타일의 API를 뜻한다.

REST 제약 조건

REST 아키텍처에 적용되는 6가지 제약 조건

REST는 아래 6가지 스타일을 반드시 지켜야한다.

Client-Server(클라이언트 - 서버 구조) REST 서버는 API 제공, 클라이언트는 컨텍스트 등을 직접 관리하는 구조로 되어 있어 Server와 Client의 역할이 명확히 나뉘기 때문에 각 필드에서 개발해야할 점이 명확해지고 서로 간의 의존성이 줄어든다.
Stateless(무상태) HTTP는 stateless 프로토콜이므로 REST 역시 stateless다. 즉, HttpSession과 같은 컨텍스트 저장소에 상태 정보를 따로 저장하고 관리하지 않고, API 서버는 들어오는 요청만을 단순 처리하면 된다. 세션과 같은 컨텍스트 정보를 신경 쓸 필요가 없어 구현이 단순해진다.
Cacheable(캐시 처리 가능) REST는 웹 표준인 HTTP를 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 사용할 수 있다. 따라서 HTTP가 가진 캐싱 기능을 적용할 수 있다.
Layered System(계층화) REST 서버는 다중 계층으로 구성될 수 있으며, 보안, 로드 밸런싱, 암호화 계층 등을 추가해 구조상의 유연성을 둘 수 있고, PROXY, 게이트웨이와 같은 네트워크 기반의 중간매체를 사용할 수 있다.
Uniform Interface(인터페이스 일관성)

resource는 URL로 식별된다.
resource를 생성, 수정, 추가하고자 할 때 HTTP 메시지에 표현해야 한다.
메시지는 스스로 설명할 수 있어야 한다.(self descriptive message)
애플리케이션의 상태는 하이퍼링크를 이용해 전이되어야 한다.(HATEOAS)

Code on demand 다른 조건들과 달리 꼭 지켜야 하는 조건은 아님.(선택적 제약 조건) 서버가 실행 가능한 코드를 클라이언트로 내려보내서, 클라이언트의 기능을 동적으로 확장할 수 있게 하는 방식

URL, URI, URN

URI(Uniform Resource Identifier)는 인터넷 상에서 특정 자원을 가리키는 식별자다.
- URL과 URN을 포함하는 개념
URL은 인터넷 상에서 특정 시점에서의 자원의 구체적인 위치다.
URN은 인터넷 상에서 자원을 가리키는 영속적이고 고유한 식별자다.

URL과 URN

URL은 특정 시점에서 자원의 위치를 나타낸다.
URL은 나중에 자원의 위치가 바뀌게 되면 기존의 URL로는 식별할 수 없게된다.
URN은 자원에 대해 영속적이고 고유한 이름을 부여한다.
URN은 다음과 같은 구조를 가진다.
- urn:isbn:978321313
- URN은 urn으로 시작하고 콜론으로 구분되어 표현된다.
- ISBN은 국제 표준 도서번호를 뜻한다.
- URN은 해당 자원을 고유하게 식별한다.

XSS(Cross-Site Scripting)

사용자의 브라우저에서 악성 스크립트가 실행되도록 만드는 공격

공격자가 입력한 값(댓글, 게시글, 검색어 등)이 그대로 HTML에 삽입되고, 브라우저가 그걸 자바스크립트로 실행하면서 문제 발생.

결과
- 사용자의 세션 탈취
- 쿠키/로컬스토리지에 저장된 정보 탈취
- 피싱, 가짜 화면 표시, 임의 요청 전송 등
방어 방법
- HTML 컨텍스트: < , >, ", ', & 등을 HTML엔티티로 변환 → <script> → <script>
- 쿠키에 HttpOnly 설정
  - 자바스크립트로 document.cookie 접근 불가

CSRF(Cross-Site Request Forgery)

사용자가 로그인된 상태라는 점을 악용해서 공격자가 만든 페이지에서 피해 사이트로 사용자 몰래 요청을 보내는 공격.

스크립트 주입 없이, 사용자의 인증 상태(쿠키)를 이용해서 다른 사이트로 요청을 보내게 하는 것.

방어 방법

CSRF 토큰 사용
- 서버가 사용자의 세션/스토리지에 랜덤 토큰을 저장.
- 스프링 시큐리티같은 프레임워크는 CSRF 토큰 자동 지원.
Samsite 쿠키 옵션
- 다른 도메인에서 온 요청에 쿠키 자동 전송을 차단.
- 요즘 브라우저는 기본이 일부 GET링크를 허용하는 Lax에 가까움.

SQL Injection

사용자 입력을 그대로 SQL 문자열에 붙여서 실행할 때, 공격자가 SQL 문법을 끼워 넣어 쿼리의 의도를 바꾸는 공격

SELECT * FROM users WHERE username = '입력값' AND password = '입력값';

여기에서 username에 1=1 같은걸 넣으면, WHERE 조건을 항상 참으로 만들어 로그인 우회 같은게 가능.

방어 방법
- Parameterized Query 사용
  - SQL과 파라미터를 완전히 분리해서 사용
```
String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, username);
ps.setString(2, password);
ResultSet rs = ps.executeQuery();
```
  - ? 자리는 단순 데이터로 처리되고, SQL 문법으로 해석되지 않아서 Injection 방지
  - JPA, MyBatis 등 ORM/매퍼에서도 바인딩 파라미터(?, :name)을 사용하는 방식이 바로 이것.

웹 캐시

웹 캐시는 자주 쓰이는 자원의 사본을 자동으로 보관하는 장치이다.

웹 요청이 캐시에 도착했을 때 캐시된 사본이 존재한다면 해당 자원은 origin 서버가 아닌 캐시로부터 제공된다.

장점

불필요한 데이터 전송을 줄여준다.
- origin 서버의 부하를 줄여준다.
네트워크 병목을 줄여준다.
갑작스러운 트래픽에 대처할 수 있다.
거리로 인한 지연을 줄일 수 있다.
- 클라이언트와 서버의 거리가 멀수록 지연이 커진다.(빛의 속도는 300000km/s)

cache hit 와 cache miss

cache hit
- 캐시에 요청이 도착했을 때, 요청에 대응하는 사본이 존재한다면, 해당 요청을 처리할 수 있다. 이를 캐시 적중이라 한다.
cache miss
- 만약 대응하는 사본이 없다면 origin 서버로 요청이 전달된다.
캐시 재검사 적중
- 만약 대응하는 사본이 존재하는데, 유효기간이 만료돼서 재검사를 했을 때, 해당 사본이 최신인 경우를 캐시 재검사 적중이라 한다.

재검사

origin 서버 콘텐츠는 변경될 수 있기 때문에 캐시는 갖고 있는 사본이 최신인지 서버를 통해 점검해야 한다.
서버에 보내는 GET 요청에 If-Modified-Since 헤더를 추가하면 캐싱된 시간 이후에 사본이 변경되었을 경우만 사본을 보내달라는 의미이다.
- 만약 서버 자원이 변경되지 않았다면, HTTP 304 Not Modified 응답을 보낸다.
- 만약 서버 자원이 캐시된 사본과 다르다면, 서버는 자원과 함께 HTTP 200 OK 응답을 보낸다.
- 만약 서버 객체가 삭제되었다면, 서버는 404 NOT FOUND 응답을 보낸다.
재검사를 보내는 기준
- HTTP는 Cache-Control 과 Expire라는 특별한 헤더들을 이용해서 origin 서버가 각 자원에 유효기간을 붙일 수 있게 한다.
- 이 유효기간이 만료되면, 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해 보고, 최신의 사본을 얻어와야 한다.(새로운 유효기간과 함께)
- Cache-Controll : max-age
  - max-age는 자원의 최대 나이다.초단위 시간값이다.
  - ex) Cache-Controll: max-age=4842000
- Expires
  - 유효기간을 날짜로 명시한다.
  - ex) Expires: Fri, 05 Jul 2002, 05:00:00 GMT

종류

개인 전용 캐시(private cache)
- 한 명의 사용자에게만 할당된 캐시다.
- 웹 브라우저는 개인 전용 캐시를 내장하고 있다.
- 대부분의 브라우저는 자주 쓰이는 자원을 개인용 컴퓨터의 디스크와 메모리에 캐싱해 놓는다.
공용 프록시 캐시(public cache)
- 프록시 캐시는 로컬 캐시에서 자원을 제공한다.
- 사용자의 입장에서 서버에 접근하기도 한다.
- 공용 캐시는 여러 사용자가 접근하기 때문에 불필요한 트래픽을 더 많이 줄일 수 있다.

프록시 서버

웹 프록시 서버는 클라이언트 입장에서 트랜잭션을 대신 수행해준다.
HTTP 프록시 서버는 웹 서버이기도 하고, 웹 클라이언트기도 하다.

개인 프록시

하나의 클라이언트만을 위한 프록시를 개인 프록시라 부른다.

공유 프록시

대부분의 프록시는 공유 프록시다. 중앙 집중형 프록시를 관리하는게 더 비용효율이 높고 쉽다.

캐시 프록시 서버와 같은 프록시는 사용자가 많을 수록 유리하다.(여러 사용자들의 공통된 요청에서 이득을 취할 수 있기 때문)

게이트웨이

프록시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다.
게이트웨이는 클라이언트와 서버가 서로 다른 프로토콜로 말하더라도 서로 간 트랜잭션을 완료할 수 있도록 해주는 프로토콜 변환기처럼 동작한다.
실질적으로 프락시와 게이트웨이의 차이점은 모호하다. 브라우저와 서버의 HTTP 버전이 다를 경우 프록시는 약간의 프로토콜 변환을 하기도 하고 상용 프록시 서버는 게이트웨이 기능을 구현하기도 한다.

프락시 사용 예시

어린이 성인 사이트 필터
- 초등학교는 어린이들에게 교육 사이트를 제공하면서 동시에 성인 콘텐츠를 차단하려고 필터링 프록시를 사용할 수 있다.
문서 접근 제어자
- 프록시 서버는 많은 웹 서버들과 웹 리소스에 대한 접근을 제어할 수 있다.
보안 방화벽
- 네트워크 보안 엔지니어는 보안을 강화하기 위해 프록시 서버를 사용한다.
- 프록시 서버는 조직 안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제한다.
웹 캐시
- 프록시 캐시는 자주 사용되는 자원의 사본을 관리하고 해당 자원에 대한 요청이 오면 빠르게 제공한다.
대리 프록시
콘텐츠 라우터
트랜스 코더
익명화 프록시

포워드 프록시

Forward Proxy는 클라이언트의 요청을 대신 서버에게 보내준다.
Forward Proxy에 클라이언트의 요청한 내용을 캐싱할 수 있다.
Forward Proxy는 클라이언트가 보낸 요청을 익명으로 서버에게 전달할 수 있다. 서버는 요청으로 들어온 클라이언트의 IP 주소를 알아내지 못하고, Proxy 서버의 IP주소를 알 수 있을 뿐이다.)

리버스 프록시

일반적인 Proxy는 클라이언트 편에서 동작한다. 클라이언트가 누구인지 감추고 서버로 요청한다.

반면, 리버스 Porxy는 서버 편에서 동작한다. 서버가 누구인지 감추고 클라이언트에게 응답한다.

즉, 방향이 반대라서 리버스 프록시이다.

Reverse Proxy는 서버의 응답을 대신 클라이언트에 전달한다.
Reverse Proxy는 클라이언트의 요청을 캐싱할 수 있다.
Reverse Proxy는 실제 서버를 노출하지 않게 해준다. 클라이언트는 Reverse Proxy를 실제 서버라고 생각하고 Reverse Proxy에 요청을 보낸다.
Reverse Proxy를 활용하여 로드 밸런싱을 할 수 있다.(부하 분산)
Reverse Proxy를 한 대 두고 뒤에 여러 개의 WAS를 두는 구조에서 Reverse Proxy는 들어오는 요청의 부하를 여러 WAS로 분산 시켜줄 수 있다.

커넥션 타임아웃

서버와의 TCP 연결을 맺는데 최대 얼마까지 기다릴 것인가를 의미한다.

클라이언트가 서버 IP/포트로 TCP연결을 시도할 때, 서버가 죽거나 네트워크에 문제가 있거나 방화벽에 막힌다면 연결이 아예 안 맺어질 수 있다. 이때 얼마나 기다리다가 포기할지를 정하는 값이 커넥션 타임아웃.

값 설정 시 고려할 점
- 너무 크면 연결 시도 중에 많은 연결 시도가 묶이게 되어 스레드/커넥션 고갈로 서버 장애로 이어질 수 있다.
- 너무 작으면 잠깐 네트워크가 느려졌을 때도 타임아웃이 자주 발생한다.
- 내부망 서비스는 0.5~3초로 설정하고 모니터링 하면서 조정한다.

리드 타임아웃

연결은 성공했는데 서버 응답 데이터를 읽을 때 최대 얼마까지 기다릴 것인가를 의미한다.

readTimeout=5000ms 는 응답 바디를 읽기 시작하고서 5초 동안 데이터가 안 들어오면 타임아웃.

값 설정 시 고려할 점
- 너무 크면 트래픽 많은 서비스에서 높처럼 스레드가 빠져나오지 못해 전체 장애를 부를 수 있다.
- 너무 작으면 조금만 응답이 느려도 바로 예외가 발생한다.
- 실무에서의 설정
  - 내부 API: 1~5초
  - 외부:3~10초

'네트워크' 카테고리의 다른 글

[컴퓨터 네트워크] 네트워크 레이어 (0)	2025.12.15
[컴퓨터 네트워크] TCP & UDP (1)	2025.12.09
[컴퓨터 네트워크]애플리케이션 레이어 (0)	2025.11.26
[컴퓨터 네트워크] 네트워크 기초와 로드 밸런싱 기법 정리 (0)	2025.11.20

쿠키와 세션의 차이

사용 이유

쿠키(Cookie)

세션(Session)

쿠키와 세션의 차이

Q. 세션을 사용하면 좋아보이는데 쿠키를 왜 사용할까?

JWT 토큰

구조

헤더(Header)

페이로드(Payload)

서명(Signature)

JWT 생성과 검증

JWT토큰과 세션의 차이

리프레시 토큰이 사용되는 이유

리프레시 토큰과 세션의 차이점?

SOP란

CORS란

Rest API(Representational State Transfer)

REST 제약 조건

REST 아키텍처에 적용되는 6가지 제약 조건

URL, URI, URN

URL과 URN

XSS(Cross-Site Scripting)

CSRF(Cross-Site Request Forgery)

SQL Injection

웹 캐시

장점

cache hit 와 cache miss

재검사

종류

프록시 서버

개인 프록시

공유 프록시

게이트웨이

프락시 사용 예시

포워드 프록시

리버스 프록시

커넥션 타임아웃

리드 타임아웃

'네트워크' 카테고리의 다른 글

티스토리툴바