서론
CS는 개발자의 포텐셜
서버는 구조를 바꾸기 어렵다.
TPS(Transaction Per Second) :서버가 초당 처리한 사용자 요청의 수
처리 가능한 최대 TPS -> 서버 성능 판단 가능 (동시 사용자와는 다름)
동시 사용자(Concurrent Users : 접속 사용자 중 현재 시스템을 사용하고 있는 사용. (동시 접속자)
부하 사용자(Action Users) : 동시사용자 중 트랜잭션을 발생하여 결과를 기다리고 있는 사용자. (TPS)
Saturation Point (서버의 TPS는 계속 늘어나지만, 특정 시점 이후로는 TPS가 더 이상 증가하지 않음(즉 대기시간이 길어짐))
허나 서버를 늘린다고 무조건 TPS가 증가하지 않음.
또한 서버는 24시간 돌아가기 때문에 안정성이 중요. RAM 사용량 등 다방면 고려해야함.
서버는 어떻게 요청을 처리할까?
원격 프로세스는 직접 통신이 불가능해서 소켓을 이용해 진행함.
Port : 통신에서 애플리케이션이 상호고분을 위해 사용하는 번호
Socket : 네트워크 상에서 돌아가는 두 프로그램 간 양방향 통신의 앤드포인트
(똑같은 서버로 서로 다른 요청이 들어올 때, 어떻게 구분할 것인가?)
기본적으로, 대부분의 서버는 Request가 올 시 이에 대응하는 프로세스/스레드가 필요 -> 일일이 만들면 Context Switching이 과도하게 발생되어 성능 저하 발생.
톰캣 -> 사용자의 오청을 처리할 스레드를 미리 만들어 놓고, 요청이 들어올 때 마다 스레드를 통해 처리하는 방식을 사용함
c10k problem
한 번에 10000개의 요청을 동시에 처리할 수 있냐?
ulimit : file descriptors : 256 -> 소켓도 최대 256개만 열 수 있음
프로세스의 필요에 따라 Hard Limit까지 올릴 수도 있음(81920개 (맥북 특정 버전기준)
MySQL 또한, 커넥션 별로 소켓을 열어서 관리하고 있음 (214개 + a)
즉, 최대 연결 수가 변경되지 않으면, soft limit 값을 확인해야 함.
HTTP
HTTP 는 W3 상에서 정보를 주고 받을 수 있는 프로토콜. 주로 TCP를 사용
HTTP/3부터는 UDP 사용
TCP - 더 빠르게 할 수 없을까?
HTTP/1.0 시절에는 HTML, JS파일, CSS 파일 이기 때문에 각각 3way Handshake를 함. 즉 3번 이 과정을 진행
HTTP/1.1 시절에는 HTML, JS파일, CSS 파일 을 한번에 TCP Handshake를 해서 빨라짐.
옛날에는 새로고침을 3번하면 3번 HandShake
지금은 Web Cache를 통해 TCP Handshake 총 1회(캐시 정책에 따라 0회일 때도 있음)
하지만
같은 서버에서의 다른 주소에 대해서 3번 호출 시 TCP Handshake를 총 3회 함
한 번 신뢰성 획득하면 그 이후로는 안해도 되는 것을 활용한 것이 TCP Fast Open
DHCP에서 UDP 사용 이유
DHCP : IP가 없을때 IP를 달라고하는 것
클라이언트는 DHCP가 서버가 어딨는지 모르므로 연결된 모든 곳에 쏨 -> 모든 DHCP가 다 응답을 줌. 클라이언트가 가장 빠른 거 받음
TCP -> Hanshake 과정 필요 -> 모든 통신이 1:1로 이루어져야 함.(Unicast)
즉, Broadcast(로컬 네트워크에 연결된 모든 곳에 요청) -> TCP 사용 불가
& IP 는 3계층 TCP 는 4계층
