Spring (1) Network, Web

destro·2025년 4월 22일

2. Spring

목록 보기

1/17

1. 네트워크

📚 프로토콜(Protocol) : 컴퓨터 간에 데이터를 주고받기 위해 정한 통신규약.

📚 인터넷 프로토콜 IP(Internet Protocol) : 인터넷 네트워크에서 정보를 수신, 송신하는 통신에 대한 규약

📚 IP 주소 : 각 기기 간의 통신을 식별하는 전화번호. 지정한 IP 주소에 데이터를 Packet 단위로 전달

📚 Packet : 소스 IP(출발지), 대상 IP(도착지)를 포함하므로 어떤 컴퓨터에 데이터를 전송할지 판별 가능

Packet은 크게 헤더, 페이로드, 트레일러(수신여부 포함)로 구분. 데이터를 받고 응답

📌 IP 방식의 문제점

애플리케이션 구분 : 대상 컴퓨터의 어떤 프로그램에 사용될 데이터인지 구분 불가
비연결성 : 수신 대상의 현재 상태에 상관없이 데이터를 전송
비신뢰성 : 패킷 소실 발생, 손상여부를 알 수 없으며 순서가 뒤죽박죽 섞여서 들어오는 경우 발생
❗ 용량이 큰 데이터는 패킷이 여러개로 나뉘어져 전송됨
👉 패킷 손실, 오류 발생 시에도 데이터를 재전송하지 않음 → TCP 프로토콜로 해결

Ⅰ. TCP(Transmission Control Protocol)

📚 서버와 클라이언트 간 데이터를 신뢰성 있게 전달하는 프로토콜

3 Way HandShake : 물리적으로 연결X, 최소한의 논리적 연결을 통해 연결 되었다고 가정하는 것
SYN (Synchronize)
- 클라이언트가 서버에게 연결을 요청하는 첫 번째 단계
- 서버에게 "연결을 시작하고 싶다"는 의사를 나타내기 위해 SYN 플래그가 설정된 패킷을 전송
- 패킷에 시퀀스 번호 포함됨. 데이터 전송 순서 관리를 준비함.
ACK (Acknowledge)
- 서버가 클라이언트의 SYN 패킷을 받고 확인신호를 보내는 단계
- 서버는 클라이언트의 SYN 요청을 수락하며, 자신도 연결을 시작하고 싶다는 뜻을 담아 SYN 플래그와 함께 ACK 플래그가 설정된 패킷을 클라이언트에게 전송
- 서버는 클라이언트의 시퀀스 번호에 1을 더한 값을 ACK로 응답

1. SYN 접속 요청
2. ACK 요청 수락 → ACK가 없다면 연결 실패.
3. ACK → ACK 함께 데이터 전송 가능

데이터 전송 여부 👉 TCP로 통신시 데이터를 잘 받았다는 응답 반환

패킷 순서 👉 패킷이 나뉘어져 와도 순서 보장

💡TCP는 신뢰성이 있지만 연결 과정, 데이터 전송에 시간이 많이 소요되며 현재 단계 이상의 최적화가 힘듬
  (최소한의 논리적 연결이 필요) → 3 way handshake 과정을 거치기에 속도가 느림

Ⅱ. UDP(User Datagram Protocol)

📚 비연결형, 신뢰성 없는 전송 프로토콜. 현대에는 UDP를 많이 사용함 HTTP3
실시간 통신이나 스트리밍에서 중요한 빠른 전송 충족을 위해 개발됨

특징
1. IP 방식과 거의 비슷하며 3 way handshake를 하지 않음
2. 데이터 전송, 응답, 순서를 보장하지 않음 비신뢰성
3. 추가적인 기능이 거의 없으며 연결을 하지 않는 대신 속도가 빠름
4. IP와 다르게 PORT 존재 TCP에도 PORT가 존재함
5. 데이터 무결성 검사 → 체크섬(Checksum) 포함 잘못된 데이터 전송 방지

Ⅲ. PORT

📚 같은 IP 내에서 프로세스 구분을 위해 사용. IP 주소가 같을 때 패킷의 도착지를 식별하는 방법

👉 PORT는 아파트 호수와 같은 역할

TCP/IP Packet 구조 : 소스 PORT, 대상 PORT를 포함

📌 자주 사용되는 PORT

0 ~ 65535 할당 가능
이미 사용되고 있는 포트 (0 ~ 1023) : 국제 도메인 관리기구가 관리하므로 비사용 권장
- FTP - 20, 21 (TCP)
- SSH - 22 (TCP)
- 텔넷 - 23 (TCP)
- SMTP - 25 (TCP)
- DNS - 53 (TCP/UDP)
- DHCP - 67 (UDP)
- HTTP - 80 (TCP)
- HTTPS - 443 (TCP)
- RDP - 3389 (TCP/UDP)
- 실제 개발진행시 미사용중인 포트를 사용하여 개발

2. 웹 기초

Ⅰ. DNS(Domain Name System)

📚 사람이 읽는 도메인 이름을 컴퓨터가 읽는 IP 주소로 변환

DNS 등장 이유
1. IP 주소는 사이트마다 특징도 없고 길어서 외우기 힘들며 IP 변경시 새로운 IP에 접근 불가
2. IP는 변경되는 주소 (가정집은 유동IP 사용)
DNS 동작 순서
1. 원하는 이름의 도메인 구매 후, DNS 서버에 등록
2. 도메인명 입력시 DNS 서버는 IP 주소를 반환

IP 변경시 DNS 서버에 등록된 IP 주소만 바뀌면됨
IP주소 형태가 아닌 https://naver.com 등의 도메인 형태로 웹에 접속. URL이 DNS를 활용한 예

Ⅱ. URI(Uniform Resource Identifier)

📚 인터넷 자원(Resource)을 나타내는 고유 식별자(Identifier)

💡 ISBN (International Standard Book Number) : 국제 표준도서번호

URI(Uniform Resource Identifier)
- 인터넷 자원(Resource)을 식별할 수 있는 문자열
- Locator, Name 혹은 둘 다 추가로 분류 가능
URL(Uniform Resource Locator)
- 자원(Resource)의 위치. 일반적으로 도메인주소로 알려져 있으며 프로토콜이 포함됨
- URL 방식의 한계 : 리소스 위치 변경시 기존 URL 사용 불가
  - 특정 사이트 검색시 출력되는 주소를 바꾸면 기존의 주소만 알던 사람들은 검색 사이트의 URL이 업데이트되지 않으면 페이지를 찾을 수 없는 현상을 극복하기 위해 URN이 등장함
URN(Uniform Resource Name)
- 리소스의 이름. 리소스 위치가 변경되어도 이름으로 리소스를 찾으므로 잘 동작함
- 프로토콜 미포함. URN으로 실제 리소스에 접근하는 방법은 대중화 되어있지 않음
💡 현재 대부분은 대중화된 URL을 사용하여, URI를 URL과 같은 의미로 사용

Ⅲ. URL 구조

⭐ scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
ex) https://www.google.com:443/search?q=스파르타+코딩클럽

scheme
- 주로 프로토콜 사용. 웹에서는 http, https, ftp를 주로 사용.
- http**s**는 http에 보안(Secure)을 추가한 것

user[:password]
- 사용자 정보. URL은 보안에 취약하여 사용하지 않음

host[:port]
- 호스트명 : 도메인 명(www.google.com) 또는 IP 주소를 직접 사용
- http : 80, https : 443 포트 사용 포트는 일반적으로 생략

[/path]
- 리소스의 경로. 계층구조로 구성
  ex) 프로토콜://쇼핑몰주소/products/macbookPro
  ex) https://nbcamp.spartacodingclub.kr/backend

[?query]
- key=value 형태로 구성됨. Query Parameter, Query String 라고도 함
- ?로 시작되고 &으로 구분
  ex) ?key1=value1**&**key2=value2**&**key3=value

[#fragment]
- html 내부 북마크 등에 사용. 전달받은 URL로 접속 시 특정 위치(fragment)로 이동 가능
  ex) http://www.google.com/index.html#image

Ⅳ. 브라우저에 URL 입력시 요청이 흘러가는 순서

https://www.google.com:443/search?q=스파르타+코딩클럽&hl=ko URL 입력
DNS 서버를 조회하여 www.google.com 에 해당하는 IP 주소를 응답받음
👉 포트 번호는 생략. https에서 사용되는 PORT는 443
웹 브라우저에서 HTTP 요청 메세지를 생성
요청 패킷(HTTP 메세지 포함)을 구글 서버로 전송
구글 서버에서 HTTP 요청 메세지를 기반으로 응답 HTTP 메세지를 만들어 응답
응답패킷 도착 → HTML 응답

3. 프로그래밍 명명규칙(Casing)

snake_case
- Python이나 DB Table, Column에 사용
- 문자와 문자 사이를 _ 언더바로 이어줌. 모든 단어는 소문자나 대문자

camelCase
- Java, JavaScript, TypeScript에서는 변수, 함수, 메서드 이름 생성시 사용
- 문자와 문자 사이를 대문자로 이어줌

PascalCase
- 대부분의 프로그래밍 언어에서 클래스 이름을 지정할때 사용
- 문자의 처음 시작은 대문자. 문자와 문자 사이는 대문자로 이어줌

kebab-case
- 문자와 문자 사이를 - 대시로 이어줌. 모든 단어는 소문자

📌 Java의 명명법

4. JSON

📚 클라이언트와 서버간 통신시 사용하는 데이터 양식.
클라이언트와 서버가 사용하는 언어에 관계 없이 통일된 데이터를 주고받도록 해줌

JSON은 사람, 기계 모두 이해하기 쉬우며 용량이 작음
XML 대체제로 데이터 전송 등에 많이 사용
Web 세계에서는 JSON(JavaScript Object Notation)을 공통어로 사용
클라이언트 to 서버, 서버 to 서버의 통신에 사용

MSA(MicroService Architecture) : 아주 작은 단위로 서비스를 잘게 나누어 운영하는 아키텍처
💡참고자료

👉 해당 아키텍처를 가지게 되면 구성된 Application마다 어떠한 언어를 사용하는지에 상관없이 서로 통신을 할 수 있는데 이것이 가능한 이유는 JSON 형태로 데이터 통신을 하기 때문

JSON 구조

 {
  "user": [
    {
      "first_name": "wonuk",
      "last_name": "Hwang",
      "age": 100,
      "phone_agree": false,
      "hobby": ["Java", "Spring"]
    },
    {
      "firstName": "sparta",
      "lastName": "Team",
      "age": 200,
      "phone_agree": true,
      "hobby": ["React", "Spring", "Node"]
    },
  ]
}

snake_case, camelCase 모두 사용 가능. Application 내에서 변환해주는 무엇인가가 있다.
key-value 형태로 구성
null, number, string, array, object, boolean 형태의 데이터 사용가능

5. Scale Up, Scale Out

📚 서버의 성능 향상을 위한 두 가지 방법

1. Scale Up : 수직적 확장

단일 서버 하드웨어의 사용을 높인다. (CPU, Memory 등의 스펙을 높인다)
요청에 대한 처리를 더욱 빠르게 하도록 해줌

2. Scale Out : 수평적 확장

같은 사양의 서버(인스턴스)를 여러 대 배치
동시에 더 많은 사용자 요청을 처리하도록 해줌

6. Stateful, Stateless

📚 클라이언트와 서버간의 통신 상태(state) 유지 여부에 따라 나뉘는 특성

1. Stateful : 클라이언트의 상태 유지

상담원은 수강생의 요청들을 기억(상태 유지)하여 다음 질문들에 대한 처리 가능
Stateful 방식의 문제점 : 같은 서버가 유지되어야함
- 서버는 시스템 에러, 비지니스 로직 문제, 리소스 부족 문제 등으로 동작중단될 수 있음
- 요청 트래픽이 몰리면 상태유지에 리소스가 많이 소모됨 → 서버 종료, 다음 요청처리 느려짐

2. Stateless : 클라이언트의 상태를 유지하지 않음

Stateless 방식의 실제 요청방식
- 강의를 신청하려는 수강생이 상담한 직원이 아닌 다른 직원이 와도 신청할 수 있게 됨
장점 : 같은 서버 유지 불필요, Scale Out 수평 확장성 높음, 갑자기 요청량이 증가해도 서버 증설 쉬움
단점 : 클라이언트가 데이터를 추가적으로 전송해야 함. 전송되는 데이터의 양이 많아짐
한계점 : WebApplication을 만들때 서버의 확장성을 고려하여 최대한 Stateless하게 만들어야 함
→ 실제로는 로그인처럼 상태 유지가 필요함 → Cookie, Session, Token 등으로 한계 극복

7. Connection, Connectionless

📚 클라이언트와 서버 간의 연결(Connection) 유지 여부에 따라 나뉘는 특성

1. Connection(연결)

서버는 클라이언트와 연결을 유지하기 위해서 자원을 소모
- 수많은 사람들이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청은 작음
- 클라이언트 2, 3이 아무런 요청을 안해도 연결을 유지
장점 : 새로운 연결 과정이 필요없음 → 응답 속도가 빨라짐
단점 : 클라이언트가 지속적인 요청을 한다는 보장이 없음 → 연결을 위한 자원 낭비

2. Connectionless(비연결)

클라이언트와 서버가 연결을 유지하지 않고 서버는 최소한의 자원만을 사용
ex) 브라우저가 켜진 상태에서 인터넷이 종료되어도 홈페이지는 정상노출
장점 : 효율적인 서버자원 사용
단점
- 요청이 추가되면 연결(3 way handshake)을 새로 해야함 → 응답 시간 증가
- 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 함
  → 캐시, 브라우저 캐싱으로 해결 (임시저장)
- 현재는 HTTP 지속연결(Persistent Connections) 로 문제 해결