[우아한테크코스] 7월 5일 TIL

[JPA] Auditing

• application이나 config 클래스 상단에 @EnableJpaAuditing 어노테이션 추가
  시점 들어가는 클래스 상단에 콜백 리스너 @EntityListeners(AuditingEntityListener.class) 어노테이션 추가
  생성 시점: @Created 어노테이션 추가
  마지막 변동 시점: @LastModified 어노테이션 추가

[network] 흐름제어와 오류제어

전송의 과정

1. 송신측 transport layer: application layer에서 받은 message를 segment로 나누어 network layer에 전달
2. 수신측 transport layer: network layer에서 받은 segment를 message 단위로 합쳐 application layer에 전달

TCP VS UDP

• TCP: 흐름제어, 혼잡 제어, connection setup(가상의 연결), data re-transmit(data loss 안되도록 함), 데이터가 data stream으로 전달되고 송신측이 보낸 순서와 수신측이 받는 순서가 같다.
• UDP: TCP가 하는 모든 일을 하지 않고 데이터를 data segment 형식으로 전달한다.
  둘다 속도, 시간에 대한 보장은 하지 않는다.

흐름제어

수신측이 수용할 수 있는 용량에 따른 송신측의 전송 속도 조절로 송신측과 수신측 간의 데이터 처리 속도 차이를 해결하고자 한다.
송신측에서 하나씩 데이터를 보내고 그게 정상적으로 보내져야만 다음 데이터를 보내는 방식은 매우 비효율적이다.
따라서 송신측은 앞에 보낸 데이터에 응답이 오지 않더라도 더 많은 데이터를 보낼 수 있는 방식을 취한다. (Sliding window)
송신측은 수신측이 감당할 수 있을 정도의 속도를 유지하며 전송한다. 수신측은 처리가 어려운 경우 버퍼를 이용해 데이터를 저장한다. 하지만 공간이 부족하면 발생하는 손실을 막기 위해 다음에 수신할 프레임의 전송 시점을 송신측에 통지한다. 받을 수 있는 데이터의 양도 송신측에 알려준다.

1. 송신측이 데이터를 보낸다.
2. 송신측은 send buffer에 데이터를 저장하고 수신측은 receive buffer에 데이터를 저잘한다.
3. 어플리케이션이 준비가 되면 receive buffer에 있는 것을 읽기 시작한다.

4. 수신측은 송신측에 자신의 buffer에 얼마나 남았는지 feedback한다.

   • Stop and Wait
     매번 전송한 패킷에 대해 확인 응답을 받아야지만 다음 패킷을 전송하는 방법이다.
     a가 가고 a가 정상 도착했음을 인정받아야 다음 패킷을 전송한다.
     느리다.
   • Sliding Window(Go Back n ARQ)
     수신측에서 설정한 윈도우 크기만큼 송신측에서 확인응답없이도 세그먼트를 전송할 수 있게 해 데이터 흐름을 동적으로 제어한다.
     윈도우는 단위 시간에 보내는 패킷의 수다. 한 윈도우에 있는 패킷들을 전송하고 확인되는대로 땡겨서 보낸다.
     윈도우의 크기는 최근 ACK로 응답한 프레임 수 - 이전에 ACK 프레임을 보낸 프레임 수이다.
     01234 면 전송하고 확인되면 한 칸씩 땡긴다 12345, 23456, 34567 ,,,
     수신측과 송신측 모든 호스트들은 송신, 수신을 위한 window를 두개씩 가지고 있다. 호스트들은 three-way-handshaking을 통해 수신측의 receive window size에 맞게 send window size를 맞추는 과정을 거친다.
     그렇게 사이즈를 맞추고 그만큼 보내고 확인 응답을 받은 걸 빼고 그 다음걸 넣고 하면서 같은 사이즈에서 queue 형식으로 넣고 빼면서 데이터를 전송한다.

   01234, 12345, 23451 하면 1이 아직 전송 확인이 안된거
   참고

혼잡제어

network 상태에 따른 송신측의 전송 속도 조절로 네트워크의 데이터 처리 속도와 송신측의 데이터 전송 속도 차이를 해결하고자 한다.
하나의 라우터에 엄청 많은 데이터가 도착하면 수신측이 모두 감당할 수 없게 되고 데이터 손실이 발생해 계속 재전송을 해야한다. 이러한 복잡함을 혼잡제어가 줄여준다.
송신측/수신측만 다루는 흐름제어에 비해 호스트(송신)와 라우터(네트워크)를 포함한 넓은 범위의 제어이다.

• Additive Increase / Multiplicative Decrease
  처음에 하나씩 패킷을 보내고 잘 도착하면 1씩 증가시켜가며 전송한다.
  전송이 실패하거나 일정 시간을 넘으면 패킷을 보내는 속도를 절반으로 줄인다.
  단점은 초기에 1로 시작해야해서 윈도우 크기 잡는데에 오랜 시간이 걸리고 네트워크가 혼잡해지고 나서야 크기를 줄인다는 것이 있다.
• Slow Start
  aimd 방식은 처음에 그 크기를 찾는데에 너무 오래걸려서 도입한 방식이다.
  패킷을 하나씩 보내면서 문제없이 도착하면 ack 패킷마다 크기를 1씩 늘린다.
  하나의 주기가 지나면 크기가 두배가 된다.
  그렇게 보내다가 문제가 발생하면 크기를 다시 1로 바꾼다.
  문제가 발생했던 크기의 절반까지 2배씩 증가시키고, 그 이후로는 다시 1씩 늘린다.(혼잡 회피, Congestion Avoidance)
• Fast Retransmit
  수신측에서 순번에 맞지 않는 패킷이 도착한 경우에도 긍정 응답을 보낸다.
  송신측은 순서대로 도착한 패킷의 마지막 패킷을 기준으로 다시 패킷을 보내므로 중복 패킷을 받게 된다. 그러면 문제가 되는 패킷도 다시 보내게 된다.
  같은 순서를 3개 받으면 문제가 일어난 것을 감지하고 재전송하고 window의 크기를 줄인다.
• Fast Recovery
  혼잡해지면 1이 아닌 절반으로 줄이고 선형증가하는 방법
  참고

오류제어

데이터가 중간에 손실되지 않았는지, 변형이 일어나지 않았는지 확인하고 제어한다.

1. 수신 측이 긍정 응답 ACK을 보냄으로써 정상적으로 받았음을 알 수 있다.
2. 일정 시간 동안 긍정 응답이 오지 않으면 중간에 손실되었다고 판단하고 프레임을 재전송한다.
3. 그냥 데이터만 주고 받으면 올바른지 아닌지 알 수 없어 제어 정보를 붙여 전송한다.
4. 수신측은 옳지 않은 데이터 전송이 이루어졌다고 판단하면 부정 응답을 보내거나, 무대응으로 응답한다. 부정 응답이 오면 바로 송신측에 옳지 않다고 보내 빠른 처리가 가능하지만 무대응의 경우 타임 아웃이 될 때까지 기다려야 해서 오래걸린다.
5. 정상 응답이 손실되면 송신측은 데이터 재전송을 할텐데 수신측은 다시 받은 이 데이터가 또 받은 데이터인지, 새로운 데이터인지 알지 못한다. 이를 해결하기 위해 송신측은 순서 번호를 붙인다.

그래서 진짜 하는건?